Комментарии 107
Да, термины меняются со временем.
Меня учили, что программирование состоит из следующих этапов:
- Анализ предметной области.
- Построение модели предметной области.
- Уточнение задач, которые необходимо решить в рамкмх предметной области (постановкой исходных задач явно или неявно занимается пользоаатель).
- Построение алгоритма решения задач, включая алгоритм взаимодейсьвия пользователя с программой или программным компоексом.
- Разработка архитектуры программы или программного комплекса, реализующего алгоритм.
- Реализация алгоритма в соответствии с выбоанной архитектурой в виде кода на языке программирования.
- Исправление ошибок, допущенных на всех этапах.
- Сборка программы или программного комплекса.
Тестирование и реализация обратной саязи с пользователем к программированию уже не относится, но могут быть реализованы частично или полностью посредством программирования.
А разработка ПО включает помимо программирования еще тестирование, организацию обратной связи, планирование рабочего времени, управление персоналом (даже если весь персонал — один человек).
То же, что названо программированием, у нас называлось кодированием.
НЛО прилетело и опубликовало эту надпись здесь
Зачем плодить сущности сверх необходимости?
Есть номинальные понятия, связанные с тем, какую функцию выполняет человек в определённый момент времени. Есть определённые позиции или вакансии. Вопрос в том, что является результатом своего труда.
Если результатом труда является программа, то речь идёт о программировании. В конце-концов, программа (в самом широком смысле) — это упорядоченная (в том числе, и во времени) совокупность предписаний, что и когда делать, позволяющая перевести систему из одного положения (полное отсутствие автоматизации) в другое (полная автоматизация всех бизнес-процессов).
Роли, здесь, не играют… никакой роли.
Хорошие программисты могут, конечно, между собою называть плохих программистов «кодерами», но особого смысла в этом нет. Другое дело, что в программировании для большинства программистов можно найти более продвинутых программистов, умеющих что-то ещё. В итоге, хороший программист — это тот прграммист, который знает, что ему всегда надо узнать что-то ещё. В этом смысле, все классификации заведомо слабы, поскольку никак не учитывают живую природу человека, который, если он не бездельник, завтра будет, уж точно не таким, как вчера.
Есть номинальные понятия, связанные с тем, какую функцию выполняет человек в определённый момент времени. Есть определённые позиции или вакансии. Вопрос в том, что является результатом своего труда.
Если результатом труда является программа, то речь идёт о программировании. В конце-концов, программа (в самом широком смысле) — это упорядоченная (в том числе, и во времени) совокупность предписаний, что и когда делать, позволяющая перевести систему из одного положения (полное отсутствие автоматизации) в другое (полная автоматизация всех бизнес-процессов).
Роли, здесь, не играют… никакой роли.
Хорошие программисты могут, конечно, между собою называть плохих программистов «кодерами», но особого смысла в этом нет. Другое дело, что в программировании для большинства программистов можно найти более продвинутых программистов, умеющих что-то ещё. В итоге, хороший программист — это тот прграммист, который знает, что ему всегда надо узнать что-то ещё. В этом смысле, все классификации заведомо слабы, поскольку никак не учитывают живую природу человека, который, если он не бездельник, завтра будет, уж точно не таким, как вчера.
Это уж точно.
Не путайте разработку ПО и программирование,
Не путайте постройку домов и строительство,
Не путайте написание книг и писательство…
Не путайте разработку ПО и программирование,
Не путайте постройку домов и строительство,
Не путайте написание книг и писательство…
Да. Всё это должно быть так. Но, к сожалению, так происходит не всегда. Часто один и тот же человек вынужден совмещать различные функции.
Но, лучше не «спотыкаться о термины», а говорить о том, что можно и нужно писать хорошие программы, а можно (хотя и это неприемлемо) писать плохие. Можно расписать красивую структуру требований и подзадач, но ошибиться в анализе и промахнуться в реализации. Недаром, говориться «Семь раз отмерь...». Кто же просит программиста стразу резать? Никто. Только он сам.
Но, лучше не «спотыкаться о термины», а говорить о том, что можно и нужно писать хорошие программы, а можно (хотя и это неприемлемо) писать плохие. Можно расписать красивую структуру требований и подзадач, но ошибиться в анализе и промахнуться в реализации. Недаром, говориться «Семь раз отмерь...». Кто же просит программиста стразу резать? Никто. Только он сам.
Да я полностью согласен с тем что создание простых программ серьезно отличается от разработки ПО.
В любом случае, новичок, который решил стать опытным — программистом им в конце концов станет.
Но вот что меня немного смущает так это то что автор проявляет интерес к разным направлениям разработки и делает вывод на этом буквально следующий, а именно то что если обычный программист занимается в течение 10 лет разработкой всего подряд, то он может худо да бедно назвать себя опытным, а если другой разработчик занимается только мобильной разработкой, то он ещё не разработчик ПО так что ли? (1-3 года опыта)
Разработка программного обеспечения — занятие скорее относительно для всех кто действительно хочет и может этим заниматься.
Программист – это больше чем профессия это проявление истинного творца сравнимое с самим богом. Создание (творения) своей формы жизни правда пока не совершенной к примеру ИИ, умное ПО – (Симуляция жизни) или просто обычное приложение — всё это и есть результат программирования.
Как правило опыт может приобрестись быстро или медленно всё относительно того чем вы занимаетесь.
Допустим вы достаточно компетентны в Front-end но у вас нет опыта в Back-end и это нормально, так как это не делает из вас не до программиста!
Дело в том, что Программист учиться всю жизнь — но не программировать, а в покачивание своего Skill путём приобретения опыта в разработке!
В любом случае, новичок, который решил стать опытным — программистом им в конце концов станет.
Но вот что меня немного смущает так это то что автор проявляет интерес к разным направлениям разработки и делает вывод на этом буквально следующий, а именно то что если обычный программист занимается в течение 10 лет разработкой всего подряд, то он может худо да бедно назвать себя опытным, а если другой разработчик занимается только мобильной разработкой, то он ещё не разработчик ПО так что ли? (1-3 года опыта)
Разработка программного обеспечения — занятие скорее относительно для всех кто действительно хочет и может этим заниматься.
Программист – это больше чем профессия это проявление истинного творца сравнимое с самим богом. Создание (творения) своей формы жизни правда пока не совершенной к примеру ИИ, умное ПО – (Симуляция жизни) или просто обычное приложение — всё это и есть результат программирования.
Как правило опыт может приобрестись быстро или медленно всё относительно того чем вы занимаетесь.
Допустим вы достаточно компетентны в Front-end но у вас нет опыта в Back-end и это нормально, так как это не делает из вас не до программиста!
Дело в том, что Программист учиться всю жизнь — но не программировать, а в покачивание своего Skill путём приобретения опыта в разработке!
Попробую несогласиться с вами. Я начинал писать с GUI приложений, потом приложения двух-звенные с БД, чисто sql отчеты размерами несколько тысяч строк кода, потом веб-приложения с множеством модулей, сейчас чисто backend-микросервисы. Кроме того, чисто для себя изучал программирование микроконтроллеров, писал на железе вообще без ОС. И весь этот опыт позволяет мне думать обо всех этапах работы кода, вплоть о том, как мои данные передаются и по сети и почему они могут вызвать проблему OutOfMemory на сервере на ровном месте казалось бы.
Недостаточно заниматься Front-End 10 лет и понимать при этом множество других аспектов. Это будет лишь «отличное понимаение как пишется Front-End». Автор скорее имел ввиду, что кто-то превосходно может разбираться в своей области, и это отлично, на самом деле, но недостаточно, чтобы предоставить возможность тому разработчику спроектировать новое приложение с нуля самостоятельно.
Недостаточно заниматься Front-End 10 лет и понимать при этом множество других аспектов. Это будет лишь «отличное понимаение как пишется Front-End». Автор скорее имел ввиду, что кто-то превосходно может разбираться в своей области, и это отлично, на самом деле, но недостаточно, чтобы предоставить возможность тому разработчику спроектировать новое приложение с нуля самостоятельно.
Программист – это больше чем профессия это проявление истинного творца сравнимое с самим богом
Дело в том, что Программист учиться всю жизнь
Да куда там богам до программистов. Вы вон даже «бога» пишете с маленькой буквы, а «программиста» с большой.
По-моему, для некоторых программистов в жизни куда важнее проблема, чтобы у них морда от ощущения собственной офигенности не разорвалась.
А теперь, внимание, вопрос: что будет, если, даже, создание простых программ (программ, решающих отдельные простые задачи) будет полноценной разработкой? Я усматриваю, здесь, корень проблемы. Если этого разделения не было бы, и мы относились с одинаковым вниманием к задачам различной сложности, то избежали бы множества ловушек и делали бы ПО высочайшего качества.
Во-первых, в любую минуту может придти Некто, кто попросит даже в самом простом приложении прикрутить «вот эту фичу». Современные монструозные программы (ставшие целыми пакетами!) начинались с маленьких программок.
Во-вторых, Вы всегда будете думать о том, что было бы, если бы у Вас была готовая инфраструктура для создания различных приложений, наличие которой гарантировало бы Вам определённый (высокий) уровень качества программного кода. Сколько было за последние 30 лет предложено всевозможных «фреймвёрков», многие из которых уже давно исчезли из обихода? А если бы эта инфраструктура была бы ещё и частью ОС?
В-третьих, всегда возникает соблазн разбить большие приложения на маленькие. Зачем же мы создавали многофункциональное устройство, чтобы разрезать его на части? Может быть, было бы логичнее, иметь набор маленьких приложений, решающих маленькие задачи, и средство для сборки маленьких приложений для решения больших задач по требованию пользователя (в рамках ОС).
Только, где мы найдём таких разработчиков, которые смогут выявить эти самые элементарные кирпичики и составить из них полноцветные мозаики? На этот вопрос статья ответа не даёт.
Во-первых, в любую минуту может придти Некто, кто попросит даже в самом простом приложении прикрутить «вот эту фичу». Современные монструозные программы (ставшие целыми пакетами!) начинались с маленьких программок.
Во-вторых, Вы всегда будете думать о том, что было бы, если бы у Вас была готовая инфраструктура для создания различных приложений, наличие которой гарантировало бы Вам определённый (высокий) уровень качества программного кода. Сколько было за последние 30 лет предложено всевозможных «фреймвёрков», многие из которых уже давно исчезли из обихода? А если бы эта инфраструктура была бы ещё и частью ОС?
В-третьих, всегда возникает соблазн разбить большие приложения на маленькие. Зачем же мы создавали многофункциональное устройство, чтобы разрезать его на части? Может быть, было бы логичнее, иметь набор маленьких приложений, решающих маленькие задачи, и средство для сборки маленьких приложений для решения больших задач по требованию пользователя (в рамках ОС).
Только, где мы найдём таких разработчиков, которые смогут выявить эти самые элементарные кирпичики и составить из них полноцветные мозаики? На этот вопрос статья ответа не даёт.
Тема очень хороша и актуальна для текущего состояния отрасли IT, причем, если углубиться, обсасывается уже не один десяток лет. Шикарнейшая книга есть у Стива Макконнелла — «Профессиональная разработка программного обеспечения», где на протяжении всей книги сравнивается программист и инженер ПО. Инженерия говорит о зрелости отрасли, а эту зрелость обеспечивает очень и очень много факторов, и качество написания кода это хоть и важное, но только базовое качество которым должен обладать специалист-инженер.
О зрелости стоит говорить вплоть до уровня качества инженерного образования в стране и уровня сертификации специалистов. Много ли вы знаете программистов с сертификатами? А ведь многие сервисы ее предоставляют (Zend, AWS, MySQL, т.п.). Многие если и получают их, то лишь для собственного удовлетворения. Нам до этого еще расти.
Если вы инженер высокого уровня, то вы должны делать вклад не только в свой рабочий проект, но и в отрасль вцелом. Кто пишет книги по программированию, статьи, занимается разработкой новых технологий??? Многим из нас кажется, что этим должны заниматься Facebook и Google, но на самом деле этим должен заниматься каждый инженер высокого уровня, и это, собственно, один из показателей того, что вы инженер.
Выступаете ли вы на конференциях с новыми решениями актуальных проблем, ходите ли вы на них чтобы узнать о том, с чем сталкиваются другие компании и их инженеры? Это обсуждение можно продолжать бесконечно, суть в том, что инженер это больше чем качественный программист, и нужно учиться мыслить глобальнее. Не только строчками своего кода, но и на уровне отрасли инженерии ПО вцелом.
О зрелости стоит говорить вплоть до уровня качества инженерного образования в стране и уровня сертификации специалистов. Много ли вы знаете программистов с сертификатами? А ведь многие сервисы ее предоставляют (Zend, AWS, MySQL, т.п.). Многие если и получают их, то лишь для собственного удовлетворения. Нам до этого еще расти.
Если вы инженер высокого уровня, то вы должны делать вклад не только в свой рабочий проект, но и в отрасль вцелом. Кто пишет книги по программированию, статьи, занимается разработкой новых технологий??? Многим из нас кажется, что этим должны заниматься Facebook и Google, но на самом деле этим должен заниматься каждый инженер высокого уровня, и это, собственно, один из показателей того, что вы инженер.
Выступаете ли вы на конференциях с новыми решениями актуальных проблем, ходите ли вы на них чтобы узнать о том, с чем сталкиваются другие компании и их инженеры? Это обсуждение можно продолжать бесконечно, суть в том, что инженер это больше чем качественный программист, и нужно учиться мыслить глобальнее. Не только строчками своего кода, но и на уровне отрасли инженерии ПО вцелом.
Лично мне кажется что тема надумана. Если я умею готовить и мне нужно приготовить на множество человек, то я не буду готовить только по двум причинам — 1) мне нужно заниматься чем-то ещё 2) я не умею готовить все блюда. Второе прямо говорит о том, что я не сформирован, как профессионал. И это не тот пример, когда школа не делает из на математиков, это когда первоклассник не в состоянии решить задачи выпускников. Тот разрыв, который демонстрируют на примере школы и математика, может выражаться лишь в различных профессиях, ведь создание ПО, это как аэропорт, где, естественно, все не лежит на плечах пилотов. ПО, это произведение которое играет оркестр, программирование, это написание произведения. И на примере этого. кажется что автор хочет сравнить оркестр с музыкантом.
читать пост я конечно же не буду, но по картинке, очевидно, что аффтор не понимает о чем пишет
Про повара хороший пример.
Я предпочитаю обедать дома, а не в супер-профессиональном ресторане Урюпинска или Москвы.
Дома — вкуснее.
Я предпочитаю обедать дома, а не в супер-профессиональном ресторане Урюпинска или Москвы.
Дома — вкуснее.
Рассказывал своим сотрудникам практически то же.
Покажу, пускай почитают, может Хабру поверят)
Покажу, пускай почитают, может Хабру поверят)
Недавно с друзьями рассуждали на тему «Программист, это творческая личность или нет?».
А как думаете Вы…?
А как думаете Вы…?
Думаю да, ибо как программист будет представлять себе прогу или что либо, так он ее и напишет, все равно что рисовать картину.
А это зависит от того, что это за программист.
Программист прекрасно может быть совсем не творческим ремесленником, который по стандартным правилам превращает ТЗ в код.
И программист может быть творческой личностью, творящей программный продукт, создающей его архитектуру не "по образцу и подобию", а как нечто новое, придумывающей новые приемы программирования, новые языки программирования или даже новые парадигмы программирования (насчет последнего, кажется, что уже все придумано: ООП, ФП и т.п., но чем черт не шутит, может быть, еще что-то изобретут).
И все это будет совершенно правильно именоваться "программирование".
На Хабре нельзя ставить под вопрос элитизм которым овеяна личность человека стоящего по ту сторону информационных технологий. (с) Я.
Но, иронию в сторону. Я для себя пришел к выводу, после того как перевел один текст с английского на русский, что программирование это работа переводчика. Сделав перевод, я подправил его с учетом рекомендаций читателей. И в скоре даже забыл про что был текст.
Переводчик переводит с одного языка на другой. Программист — с человеческого языка на язык машины.
Романтики в этой профессии не больше чем в профессии переводчика. И творчества соответственно тоже. Переводчик может позволить себе удачный художественный оборот, чтобы выйти из положения когда прямой перевод невозможен. На этом пожалуй все «творчество» и заканчивается.
Но, иронию в сторону. Я для себя пришел к выводу, после того как перевел один текст с английского на русский, что программирование это работа переводчика. Сделав перевод, я подправил его с учетом рекомендаций читателей. И в скоре даже забыл про что был текст.
кое-как нашел, вот
Это просто рутинная работа. Порой мучительно сложная, но при определенном навыке перевести можно все. Переводчик переводит с одного языка на другой. Программист — с человеческого языка на язык машины.
Романтики в этой профессии не больше чем в профессии переводчика. И творчества соответственно тоже. Переводчик может позволить себе удачный художественный оборот, чтобы выйти из положения когда прямой перевод невозможен. На этом пожалуй все «творчество» и заканчивается.
НЛО прилетело и опубликовало эту надпись здесь
я имею ввиду
.doc (требования) -> .java (или любой другой понятный машине язык)
.doc (требования) -> .java (или любой другой понятный машине язык)
Что за бред? Какой такой язык машины? Все что может машина — менять 0 на 1 разными способами
Да, а всё, что может человек — это поглощать органические вещества, расщеплять их, и синтезировать другие, ну и получать при этом энергию. Тоже, знаете ли, не слишком много.
Машина — это исполнитель. Она получает список команд из доступного ей набора и выполняет его. И скажите, вот например, солдат, который в общем случае умеет думать, но независимо от этого должен тупо выполнять команды командира подобно машине, он является аналогией компьютера? И если да, то переводчик, который переводит устав Красной Армии на немецкий язык, похож на программиста? ;)
НЛО прилетело и опубликовало эту надпись здесь
мне кажется все зацепились за слово переводчик, как профессию. Я же скорее имею ввиду переводчика как того, что переводит информацию из источника на язык получателя. И командир в таком случае, переводит информацию которую он получает о ситуации, в информацию (инструкции) для подчиненных, для выполнения задач.
В «защиту» своей «аналогии» процитирую еще книжку
«Решение задач на компьютерах» Москвитина А.А (с.320):
В «защиту» своей «аналогии» процитирую еще книжку
«Решение задач на компьютерах» Москвитина А.А (с.320):
Чтобы понять природу ошибок ( а это нам необходимо при переходе от неформального описания задачи пользователя к формальной реализации ее в виде программы) при переводе рассмотрим модель [...] Ha на ней человек осуществляет перевод информации из представления А в представление B.Может это более точное описание, той аналогии которую я имею ввиду.
Переводчик переводит мысли других людей, вот и все.
Не совсем так. «Человеческие» языки, если говорить о языках из разных групп, между собой отличаются очень сильно, не говоря уже о контексте, который понятен читателям И переводчик, если он не безмозглый подстрочник, это должен учитывать. Шутка про Пугачеву и Галкина в английском переводе должна превратиться в шутку про Хью и Кристал Хефнеров, а в арабском вообще исчезнуть или превратиться в шутку на другую тему.
Для машины нужно что-то типа 500 шагов на 32 градуса северо-восток, развернуться спиной к дому, присесть и тд.
Это лишь вопрос уровня абстракции. Современный программист ведь в подавляющем большинстве случаев работает с весьма высокоуровневыми библиотеками, и как раз отдает команды вида «займи позицию в доме напротив», понимая, что в библиотеке уже есть логика «зайти с заднего хода, закинуть гранату, потом под прикрывающим огнем заскочить и дать автоматную очередь». Да, её кто-то когда-то пошагово расписал, но это уже другая история.
В таком случае учитель это человек который переводит язык взрослых на язык детей, а доктор — человек который переводит крики пациента в язык движений скальпеля.
Про учителя в согласен, он переводит из ментальной модели взрослого в ментальную модель ребенка. Посредством например дидактической редукции. Доктор переводит из человеческого языка симптомов (тут болит) на формальный язык диагноза. И если заказчик (пациент) хочет это лечить врач предлагает известные ему методы избавления от симптомов и причин. (Что-то похожее на работу архитектора в айти). И передает работу хирургу, у кторого в конце концов на карточке написано что и где отрезать. Работа хирурга, практически не творческая. Но это все не значит что для этой работы не нужен талант. Талант нужен, чтобы свою функцию (ср. книги «Черновик», «Чистовик» у С. Лукьяненко) выполнять хорошо или лучше чем большинство других.
Вы уж простите за такую «механистическую» перспективу. Это всего лишь взгляд под другим углом.
Вы уж простите за такую «механистическую» перспективу. Это всего лишь взгляд под другим углом.
В работе хирурга тоже есть место творчеству.
Что-нибудь отрезать можно разными способами.
Пришить тоже.
И эти способы нужно кому-то разрабатывать, а разработкой новых методов проведения операций занимаются обычно хирурги.
книги «Черновик», «Чистовик» у С. Лукьяненко
Мне видится аналогия с более старой и ёмкой проблемой.
кодер(хирург/функция) в большей степени следует алгоритмам (догмам/рекомендациям), а разработчик(инженер/руководитель/функционал) сам эти алгоритмы составляет. По моему мнению упомянутая книга как-бы и намекает, что если твоя функция в том, чтобы совершать выбор (и большой и маленький), то ты человек творческий, а разработка чего-либо — это без сомнения очень творческий вид деятельности.
Вопрос в том, нужно ли стремится к тому чтобы стать творческим, или лучше уступить место другим?
Скорее не переводчик, а писатель или сценарист. «Напиши мне книжку про будущее и космические корабли на просторах Вселенной».
Переводчик переводит с одного языка на другой. Программист — с человеческого языка на язык машины.Забыли только, что программист иногда еще и алгоритм изобретает или адаптирует существующий под конкретную задачу. Что касается перевода с естественного языка на искусственный, то в общем случае такой перевод пока невозможен, кроме тривиальных случаев типа «два плюс два». Существующие искусственные языки даже теоретически не могут обеспечить многих соответствий с естественными. Но некоторым фантастам это не помешало выдумать, что в 22 веке все люди будут говорить на Алголе :))
вот, только что в комментариях к статье habrahabr.ru/post/341626 наткнулся:
github.com/web-standards-ru/dictionary/issues/178 — работа переводчика тоже может заставлять его адаптировать и придумывать новое. Это нисколько не тривиальная и не рутинная работа. Но это ремесло. (просто многие программисты относятся к плодам своей работы с преувеличенным трепетом, а на самом деле можно к этому просто относиться как к переводу, перевел, отредактировал, сдал, приняли, отлично, нет, отредактировал второй раз, сдал, забыл)
Однако и в дискуссии переводчиков (причем это однозначно технические переводчики, приобщенные к теме перевода) заметно напряжение, многополярность мнений, но в отличии от айтишников они никого за другое мнение не презирают, не оскорбляют, не минусуют, и не считают дураками, и в целом приветствуют эту дискуссиию.
В них нет этого ничем не оправданного элитизма, который я упоминал в изначальном комментарии и который я надух не переношу. А так все хорошие ребята.
github.com/web-standards-ru/dictionary/issues/178 — работа переводчика тоже может заставлять его адаптировать и придумывать новое. Это нисколько не тривиальная и не рутинная работа. Но это ремесло. (просто многие программисты относятся к плодам своей работы с преувеличенным трепетом, а на самом деле можно к этому просто относиться как к переводу, перевел, отредактировал, сдал, приняли, отлично, нет, отредактировал второй раз, сдал, забыл)
Однако и в дискуссии переводчиков (причем это однозначно технические переводчики, приобщенные к теме перевода) заметно напряжение, многополярность мнений, но в отличии от айтишников они никого за другое мнение не презирают, не оскорбляют, не минусуют, и не считают дураками, и в целом приветствуют эту дискуссиию.
В них нет этого ничем не оправданного элитизма, который я упоминал в изначальном комментарии и который я надух не переношу. А так все хорошие ребята.
Давайте не будем валить в одну кучу этические моменты и объективные оценки характера той или иной работы. Работа переводчика не всегда ремесло, это может быть научная работа. Пример: перевод В.П. Козырева книги Ф. Харари, Теория графов, М.: Едиториал УРСС, 2003. Переводчик — опытный математик и в его предисловии к переводу приводятся ссылки на его научные работы, опубликованные в солидных изданиях. Заслугой перевода является более четкая терминология по сравнению с оригиналом. Сам автор отмечает проблему терминологии (С.22 перевода). Кроме того добавлено много комментариев переводчика, облегчающих понимание. Интересно почему я занялся таким сравнением? — очень просто: когда пишу статью в русскоязычное издание цитирую перевод, а когда в англоязычное — оригинал.
Давайте не будем забывать, что программирование это не чисто инженерная область, но и область науки CS (computer sci., переводят как информатика). У этой науки большое пересечение с математикой. А основой всех программ являются алгоритмы. Как и в каждой науке в CS много рутины, но это не делает ее ремеслом. Хотя и в любой другой науке встречаются ремесленники — пусть это будет их личной проблемой.
Давайте не будем забывать, что программирование это не чисто инженерная область, но и область науки CS (computer sci., переводят как информатика). У этой науки большое пересечение с математикой. А основой всех программ являются алгоритмы. Как и в каждой науке в CS много рутины, но это не делает ее ремеслом. Хотя и в любой другой науке встречаются ремесленники — пусть это будет их личной проблемой.
Спасибо Вам за участие в обсуждении. Я эту дискуссию не ради базара начал, мне хочется понять, что делает этих людей особенными. Может мои наблюдения, на которых основаны, мои выводы однобоки. Потому что мне не с чем сравнить.
Мне, вобщем, не понятно, почему айтишники ставят себя всегда особняком. Ни одна инженерная профессия не порождает столько людей с завышеным самомнением, которые кичатся своими знаниями. Хотя в этой профессии нет ничего особенного. Ничего такого, что делало бы ее отличной от других профессий.
Вот когда программист начинает думать что его профессия — творческая, начинаются велосипеды и рвутся все дедлайны. Творческая работа скорее у программного архитектора.
А разработчик просто наполняет систему кодом. Как правило в сложных системах есть сложный фреймворк, но при этом каждый программист а пишет довольно простой код. Кладет свои кирпичи в раму. Но и тут находятся такие, которые кладут кирпичи поперек, поскольку ну раз нет спецификации, и никто не запрещает делать иначе, почему нет. Рама выложена кирпичами — чего тебе еще надо. Лишь бы сделать по-другому. Проявить свое творчество. Такие персонажи встречаются к сожалению. А может просто профессия засорена людьми без профильного образования.
В социальном плане эта профессиональная группа в основном состоит из крайностей. Или нерды-аутисты, или чуваки с синдромом Даннинга-Крюгера. Серединки маловато. У нас в команде из 20 человек «простых» ребят — меньше половины. К остальным, порой, не знаешь как подойти, чтобы не быть раздавленным их умственным превосходством. Не знаю с чем это связано, может и от возраста зависит.
Мне, вобщем, не понятно, почему айтишники ставят себя всегда особняком. Ни одна инженерная профессия не порождает столько людей с завышеным самомнением, которые кичатся своими знаниями. Хотя в этой профессии нет ничего особенного. Ничего такого, что делало бы ее отличной от других профессий.
Вот когда программист начинает думать что его профессия — творческая, начинаются велосипеды и рвутся все дедлайны. Творческая работа скорее у программного архитектора.
А разработчик просто наполняет систему кодом. Как правило в сложных системах есть сложный фреймворк, но при этом каждый программист а пишет довольно простой код. Кладет свои кирпичи в раму. Но и тут находятся такие, которые кладут кирпичи поперек, поскольку ну раз нет спецификации, и никто не запрещает делать иначе, почему нет. Рама выложена кирпичами — чего тебе еще надо. Лишь бы сделать по-другому. Проявить свое творчество. Такие персонажи встречаются к сожалению. А может просто профессия засорена людьми без профильного образования.
В социальном плане эта профессиональная группа в основном состоит из крайностей. Или нерды-аутисты, или чуваки с синдромом Даннинга-Крюгера. Серединки маловато. У нас в команде из 20 человек «простых» ребят — меньше половины. К остальным, порой, не знаешь как подойти, чтобы не быть раздавленным их умственным превосходством. Не знаю с чем это связано, может и от возраста зависит.
И Вам спасибо за интересную постановку вопроса.
А здесь на Хабре разве Вас давят умственным превосходством? Посмотрел список Ваших недавних комментариев: показалось, что плюсов сильно больше, чем минусов.
Довольно большая команда. Могут быть непростые взаимоотношения. Может дело в этом, а не в профессии?
К остальным, порой, не знаешь как подойти, чтобы не быть раздавленным их умственным превосходством.
А здесь на Хабре разве Вас давят умственным превосходством? Посмотрел список Ваших недавних комментариев: показалось, что плюсов сильно больше, чем минусов.
У нас в команде из 20 человек
Довольно большая команда. Могут быть непростые взаимоотношения. Может дело в этом, а не в профессии?
Спасибо за ответ. Я тут еще раз подумал, и в купе с вашим замечанием, пришел к мысли, что вполне вероятно у меня просто искаженное восприятие. Просто у меня незаконченное айти образование, и скорее всего появился комплекс, из-за которого я слишком близко принимаю когда меня поправляют люди с большим опытом работы или знаниями. Или если я задаю какой-то вопрос, то мне кажется, что мне обьясняют категоричным надменным тоном, а на самом деле это просто мой комплекс приплетает подтекст которого нет. Надо будет понаблюдать за собой.
По описанию похоже на фундаментальную ошибку атрибуции. В части про других.
P.S. На мой взгляд у вас чуть упрощённое представление о задачах программиста, однако качественно всё так и есть. Я бы просто сравнивал скорее с инженерно строительной областью. хотелки -> ТЗ -> эскиз -> архитектурный проект -> планы систем -> инструкции для рабочих. хотелки -> ТЗ -> концепция -> архитектура -> задание на компонент -> программа. И тут вопрос, что из этого входит в работу программиста.
P.S. На мой взгляд у вас чуть упрощённое представление о задачах программиста, однако качественно всё так и есть. Я бы просто сравнивал скорее с инженерно строительной областью. хотелки -> ТЗ -> эскиз -> архитектурный проект -> планы систем -> инструкции для рабочих. хотелки -> ТЗ -> концепция -> архитектура -> задание на компонент -> программа. И тут вопрос, что из этого входит в работу программиста.
Но и тут находятся такие, которые кладут кирпичи поперек, поскольку ну раз нет спецификации
К остальным, порой, не знаешь как подойти, чтобы не быть раздавленным их умственным превосходством
А как вы тогда определили, что поперек?) Можете примеры привести, может вы просто чего-то недопоняли?
Хорошо, вот коротенький пример:
внутренне система различает четыре статуса соединения, но для сторонних программных клиентов мы выдаем только два. Есть числовые константы обозначающие для программного клиента статус соединения сервиса. Интерфейс поддерживает метод проверки валидности переданного значения. Так вот, чтобы обозначить для клиента что значение на валидно, разработчик решил передавать статус соединения -1. Его нет в константах. Обьяснил тем, что на данный момент у нас только один программный клиент — это мы сами, и там они договорились с разработчиком что -1 это невалидное значение. А если появятся другие клиенты то можно с ними договориться.
Т.е. мы максимально неверно используем собственный интерфейс. Не используем метод проверки валидности значения, а используем незадекларированную константу.
Вот что про это можно сказать. У меня только полярная лисица приходин на ум.
внутренне система различает четыре статуса соединения, но для сторонних программных клиентов мы выдаем только два. Есть числовые константы обозначающие для программного клиента статус соединения сервиса. Интерфейс поддерживает метод проверки валидности переданного значения. Так вот, чтобы обозначить для клиента что значение на валидно, разработчик решил передавать статус соединения -1. Его нет в константах. Обьяснил тем, что на данный момент у нас только один программный клиент — это мы сами, и там они договорились с разработчиком что -1 это невалидное значение. А если появятся другие клиенты то можно с ними договориться.
Т.е. мы максимально неверно используем собственный интерфейс. Не используем метод проверки валидности значения, а используем незадекларированную константу.
Вот что про это можно сказать. У меня только полярная лисица приходин на ум.
А вариант, что интерфейс спроектирован неправильно, вы не рассматриваете? Если обоим разработчикам удобнее использовать -1, значит надо поменять интерфейс.
Из описания не очень понятно, что куда передается, поэтому сложно сказать как будет правильно. Я представляю так.
В метод проверки валидности надо передавать результат вызова другого метода, например для установки соединения. Если там произошла ошибка, то логично возвращать -1. А собственно, какое значение предполагается возвращать (и проверять его валидность), если в константах нет значения обозначающего ошибку? К тому же вы предлагаете использовать 2 вызова вместо одного.
Из описания не очень понятно, что куда передается, поэтому сложно сказать как будет правильно. Я представляю так.
В метод проверки валидности надо передавать результат вызова другого метода, например для установки соединения. Если там произошла ошибка, то логично возвращать -1. А собственно, какое значение предполагается возвращать (и проверять его валидность), если в константах нет значения обозначающего ошибку? К тому же вы предлагаете использовать 2 вызова вместо одного.
Данные о статусе передаются постоянно, и метод проверки валидности для того, чтобы отличать данные которые можно использовать, от тех которые нельзя. Возможно это сомнительный дизайн, но так сделано API передачи данных от системы к программным клиентам. Оно едино для всех системных компонент.
Я не знаю как правильно, я предлагаю придерживаться интерфейса. Я думаю, что если интерфейс будет в дальнейшем кем-то использоваться то, они будут работать с задекларированными константами. И получив -1 удивятся. Им придется звонить-писать нам, спрашивать в чем дело. Программист им обьяснит. Они договорятся. А можно ведь просто придерживаться интерфейса и не придется никому звонить. Вот и все. Так вот зачем эта самодеятельность. Чем она оправдана? Почему программист считает себя умнее архитектора? Вот что мне не понятно. Даже если он умнее архитектора, сделай как все делают, не переломишься ведь.
Вот возьмем работу какого нибудь мелкого гос-служащего, он же не ставит под вопрос недостатки процессов (лишние ненужные формуляры и т.п.), а просто выполняет ввереную ему работу. Но программист так не умеет.
Я не знаю как правильно, я предлагаю придерживаться интерфейса. Я думаю, что если интерфейс будет в дальнейшем кем-то использоваться то, они будут работать с задекларированными константами. И получив -1 удивятся. Им придется звонить-писать нам, спрашивать в чем дело. Программист им обьяснит. Они договорятся. А можно ведь просто придерживаться интерфейса и не придется никому звонить. Вот и все. Так вот зачем эта самодеятельность. Чем она оправдана? Почему программист считает себя умнее архитектора? Вот что мне не понятно. Даже если он умнее архитектора, сделай как все делают, не переломишься ведь.
Вот возьмем работу какого нибудь мелкого гос-служащего, он же не ставит под вопрос недостатки процессов (лишние ненужные формуляры и т.п.), а просто выполняет ввереную ему работу. Но программист так не умеет.
То есть с сервера на клиент постоянно идет поток данных? Ок, пусть так, откуда берутся значения, которые там передаются? Почему там может быть что-то отличное от констант и почему нельзя сразу передавать -1, а нужно передавать какие-то другие невалидные значения и потом их проверять?
Я не знаю как правильно
А программисты знают.
Я думаю, что если интерфейс будет в дальнейшем кем-то использоваться то, они будут работать с задекларированными константами. И получив -1 удивятся.
Ну так задекларируйте -1 в константах. Это же ваша система, и сторонних клиентов пока нет.
Так вот зачем эта самодеятельность. Чем она оправдана? Почему программист считает себя умнее архитектора?
Потому что он с этим каждый день работает. И сам в некоторой степени архитектор. А почему умнее-то? Он же не переделывал систему, а просто передает значение, это системой разрешено, он пользуется ее возможностями.
Кроме того. Вот есть метод, принимает на вход значение, возвращает валидность. Почему вы решили, что нужно обязательно использовать именно его именно в этой ситуации? Его сделали, чтобы проверять, когда валидность неизвестна. А если пришло -1, то валидность известна, и ничего проверять не надо. Вы предлагаете делать лишнюю работу… для чего? Почему нельзя просто сделать как удобнее всем?
Но программист так не умеет.
Так он и не гос-служащий. Он инженер и решает задачи.
клиент получает обьект с обновлением, и в нем содержится значение, и, используя метод проверки валидности, можно проверить валидность этого значения, т.е. можно этим значением пользоваться или нет. Например до полной калибровки системы значения невалидны и не должны отображаться.
Так вот значения не обязательно числовые, поэтому я так думаю архитектор делал булевый метод который для любого переданного значения дает валидность этого значения. С другой стороны аргументы разработчика тоже понятны. Что делать тестировщику?
Так вот значения не обязательно числовые, поэтому я так думаю архитектор делал булевый метод который для любого переданного значения дает валидность этого значения. С другой стороны аргументы разработчика тоже понятны. Что делать тестировщику?
Сказать «По документации должно быть 1 или 2, а у вас приходит -1, исправьте код или документацию» и отправить задачу разработчику.
Все равно непонятно, какое значение должен отправлять сервер, если ни одна из текущих констант не подходит? Почему нельзя использовать -1?
Все равно непонятно, какое значение должен отправлять сервер, если ни одна из текущих констант не подходит? Почему нельзя использовать -1?
ну сервер посылает 0 сервис не доступен, 1 сервис доступен, (хотя внутренне различает четыре состояния, но это клиента не интересует) При инициализации он шлет наружу 0, и то что значение не валидно. т.е. обрабатывать его рано. А в интепретации разработчика поскольку нет других клиентов, он сделал 0, 1 и -1 причем первые две задекларированы а третье значение нет. Ну вот и получается что получается, нужно будет рано или поздно переделывать.
Вернувшись к аналогии с кирпичами, может это связано с тем, что как правило есть много поля для интерпретации в API, интерфейсах, документации. И соответственно там где нет четкого определения «правильно» разработчик включает мозги и делает свою интепретацию. Которая тоже не лишена смысла.
Вернувшись к аналогии с кирпичами, может это связано с тем, что как правило есть много поля для интерпретации в API, интерфейсах, документации. И соответственно там где нет четкого определения «правильно» разработчик включает мозги и делает свою интепретацию. Которая тоже не лишена смысла.
Если 0 это сервис недоступен, то что означает -1? Видимо это какая-то другая ситуация, не учтенная при проектировании.
-1 это в понимании разработчика комбинация 0 и valid=false. Просто он это выражает одним не задекларированным значением, и фронтэнд работает с этим значением. И у этой «парочки» (наш фронтэндер + наш разработчик) на данный момент все хорошо. Но этот же поток данных может использоваться без предупреждения и другими клиентами, на то это и интерфейс. И тогда будет мягко говоря неловкая ситуация…
Вот и получается та ситуация которую я в частности критикую «я самый умный, я сделаю как я хочу и пофиг на всех остальных» и этому я не вижу никакого оправдания. Именно эта уверенность в своей правоте порой ошарашивает, нет бы хоть на минуту усомниться. Спросить архитектора или тех лида наконец.
Но не исключено, что это еще и возрастное, как правило разрабы за 30 уже не страдают такой бескомпромиссностью и уверенностью.
Или архитектор, может посмотреть на код и ляпнуть что-нибудь обидное в адрес разработчика. Зачем? Где коммуникационные навыки? Это тоже проявление ЧСВ. Можно ведь все тоже самое обьяснить нормально. Это поможет разработчику улучшить его навыки. А глупым оскорблением хорошего разработчика не воспитаешь. Вот и получается, что общаться между собой команда разработки практически не может, чтобы никогда никого не обижать. И вот о чем я говорю, что как мне кажется такое проявления ЧСВ — в особой мере присуще этой профессиональной группе.
То что по отношению к заказчику все профессионалы бывают чсв-шными от сантехника до врача — это мы знаем. Но между собой. Вот что удивляет больше всего.
Вот и получается та ситуация которую я в частности критикую «я самый умный, я сделаю как я хочу и пофиг на всех остальных» и этому я не вижу никакого оправдания. Именно эта уверенность в своей правоте порой ошарашивает, нет бы хоть на минуту усомниться. Спросить архитектора или тех лида наконец.
Но не исключено, что это еще и возрастное, как правило разрабы за 30 уже не страдают такой бескомпромиссностью и уверенностью.
Или архитектор, может посмотреть на код и ляпнуть что-нибудь обидное в адрес разработчика. Зачем? Где коммуникационные навыки? Это тоже проявление ЧСВ. Можно ведь все тоже самое обьяснить нормально. Это поможет разработчику улучшить его навыки. А глупым оскорблением хорошего разработчика не воспитаешь. Вот и получается, что общаться между собой команда разработки практически не может, чтобы никогда никого не обижать. И вот о чем я говорю, что как мне кажется такое проявления ЧСВ — в особой мере присуще этой профессиональной группе.
То что по отношению к заказчику все профессионалы бывают чсв-шными от сантехника до врача — это мы знаем. Но между собой. Вот что удивляет больше всего.
-1 это в понимании разработчика комбинация 0 и valid=false.
Хм, подождите, если состояние соединения = 0, то с использованием того специального метода нельзя получить valid = false, 0 ведь у вас присутствует в константах. То есть на валидность влияет что-то еще. О чем я и говорю — на практике появилась ситуация, не предусмотренная при проектировании.
я самый умный, я сделаю как я хочу и пофиг на всех остальных
Нет. Я инженер и сделаю так, как будет удобнее пользоваться, а также исправлю недочеты проектирования.
Спросить архитектора или тех лида наконец.
Они с этим кодом не работают. И видимо даже код-ревью не делают, иначе бы тех. лид увидел странные значения.
А раз они код не контролируют, значит таким локальным архитектором выступает сам разработчик.
Но этот же поток данных может использоваться без предупреждения и другими клиентами, на то это и интерфейс.
А почему изменить-то его нельзя? Ведь и другим клиентам может быть удобнее использовать там -1.
так вот, я тестировщик, мне что делать? Как тестировать такой интерфейс. По имплементации программиста или использовать только те константы которые задекларированы в интерфейсе. Т.е с точки зрения стороннего клиента который ни про какие -1 не знает.
А почему метод должен возвращать именно константу, обозначающую статус соединения? Кажется, что метод проверки валидности переданного значения должен возвращать булевское (логическое) значение TRUE/FALSE, а статус соединения — это должен быть отдельный объект. Логика здесь такая: если соединение установлено некорректно, то у него не может быть какого-либо собственного внутреннего статуса.
но в отличии от айтишников они
Ну так и программист это не переводчик. Инженер, аналитик, писатель. А переводчик это вон компилятор.
И да, на Хабре тоже много напряженных многополярных дискуссий, где высказывают аргументы и которые только приветствуются.
Не на Алголе, а на Логлане. %)
Научить программировать можно любого — это легко
Не соглашусь про легкость обучения программированию любого.
Недавно на хабре пролетала статья про это, но я нашел только несколько статей, про это. Краткое содержание этих статей: нет, программировать не легко, а повсеместные утверждения о том, что это легко, демотивируют начинающих программистов.
НЛО прилетело и опубликовало эту надпись здесь
Поддерживаю, особенно после The Shocking Secret About Static Types.
НЛО прилетело и опубликовало эту надпись здесь
В JS нет макросов, так что это далеко не лисп.
Коллеги, ИМХО перевод цитаты не совсем корректен:
"В компьютерных технологиях есть только две сложные задачи: недействительность кэша и придумывание названий"
— правильнее было бы "инвалидация кэша" (процесс + конкретный термин, не нуждающий в "русификации") и "придумывание имен" (более общая и частая задача — имена функций, классов и тп)
В некоторых общественных столовых такую дрянь готовят, даже я приготовлю лучше. И при этом не стыдятся называть себя поварами…
Аналогично некоторые сервисы так дряно работают, все виснет, проводится в ручном режиме, нет нужного функционала. Но как то работает, люди туда приходят.
Так что не соглашусь. Если припрет и умеете готовить — сможете приготовить и котел жратвы на 100 чел. Может и не похвалят, но с голоду не помрут.
Аналогично некоторые сервисы так дряно работают, все виснет, проводится в ручном режиме, нет нужного функционала. Но как то работает, люди туда приходят.
Так что не соглашусь. Если припрет и умеете готовить — сможете приготовить и котел жратвы на 100 чел. Может и не похвалят, но с голоду не помрут.
Каждый разработчик ПО умеет программироватьИ сразу нет. :) Взять любой средний-большой игрострой (да и инди сойдет, если там больше 1 каски) — там есть дизайнеры, художники, моделлеры, музыканты. Это разработчики? Да. Умеют они погромировать? Нет. :)
Главная задача этого текста — донести, что создание простых программ серьезно отличается от разработки ПО
Открыли Америку! Создание простых программ серьезно отличается от создания сложных программ! А создание сложных программ серьезно отличается от разработки ПО?
Разработчики ПО досконально изучают решаемые задачи, полностью понимают, как работают предложенные ими решения
Как быть с эвристическими алгоритмами? Они работают, но никто не может полностью понять, как они это делают… М.б. в разработке ПО такие алгоритмы не применяют? ;)
Разработчики ПО не считают своей работой просто написание программ — они рассуждают с точки зрения удовлетворения потребностей и решения задач. И это важно, потому что не для всякой задачи необходимо писать программу: в некоторых случаях достаточно использовать уже существующую программу
Человек, предложивший уже существующую программу — это разработчик ПО? Прихожу в магазин, прошу ОС или текстовый редактор, продавец выкладывает мне диски и коробки — он разработчик ПО! :)
У меня больше нет слов… нужна перезагрузка…
Человек, предложивший уже существующую программу — это разработчик ПО? Прихожу в магазин, прошу ОС или текстовый редактор, продавец выкладывает мне диски и коробки — он разработчик ПО! :)
Полагаю, что автор имел ввиду всего лишь повторное использование кода или программ в новом проекте. Например, разработчику IDE. нет нужды писать новый компилятор, и его можно взять готовым.
Но что получилось, то получилось.
НЛО прилетело и опубликовало эту надпись здесь
Весьма вторичный материал.
Примерно те же мысли излагает Ф. Брукс в начале «Мифического человеко-месяца» приводя отличия «программы созданной программистами в гараже» от «системного программного продукта создаваемого промышленной командой».
Примерно те же мысли излагает Ф. Брукс в начале «Мифического человеко-месяца» приводя отличия «программы созданной программистами в гараже» от «системного программного продукта создаваемого промышленной командой».
А, разве, со временем отличия не скрадываются? Не получается так, что промышленная команда (в погоне за гибкостью или, наоборот, за системностью) начинает походить на «гаражного программиста»? Когда какая-то промышленным образом разработанная система требует постоянной доработки, то, просто, мало кто воспринимает это негативно. Как можно выпустить «сырой» программный продукт? Это, конечно, сильный ход — сделать доработку частью жизненного цикла системы. Но, получается, что исправление ошибок проектирования выносится на этап эксплуатации. В реальных конструкторских разработках, хотя бы, используются натурные и полунатурные эксперименты. А в программировании таких экспериментов нет. Всё по живому.
И ещё один момент, который мало кто учитывает. Реальные приложения — это некие «конструкции», которые возведены над ОС и другими «конструкциями». Строго говоря, нельзя возвести хорошее здание без хорошего фундамента. Но программисты всегда пользуются тем, что есть. А Вы попробуйте поставить вопрос: как должна выглядеть ОС, чтобы мы писали эффективные приложения? Но тогда выяснится, что разработчики ОС просто выдали какое-то своё решение и получили за это свои деньги, а как им будут пользоваться, не подумали: продали — и ладно. А если подумали бы, то встроили бы в ОС свой родной язык программирования и среду разработки и… всё!
И ещё один момент, который мало кто учитывает. Реальные приложения — это некие «конструкции», которые возведены над ОС и другими «конструкциями». Строго говоря, нельзя возвести хорошее здание без хорошего фундамента. Но программисты всегда пользуются тем, что есть. А Вы попробуйте поставить вопрос: как должна выглядеть ОС, чтобы мы писали эффективные приложения? Но тогда выяснится, что разработчики ОС просто выдали какое-то своё решение и получили за это свои деньги, а как им будут пользоваться, не подумали: продали — и ладно. А если подумали бы, то встроили бы в ОС свой родной язык программирования и среду разработки и… всё!
Если со временем профессионалы начинают в погоне за чем-либо нарушать промышленные стандарты, то это говорит о деградации процессов. Причины могут быть разные, в т.ч. и давление со стороны маркетинга или менеджмента в погоне за скорейшей прибылью, как вы выразились. Это печально. Но время всё расставит по своим местам.
Напоминает MS + .NET + VS, как раз таки тот случай когда разработчики получили за это деньги.
Большинство альтернативных ОС, где разработчики просто выдают какое-то свое решение без родных языков и сред разработки, распространяется свободно.
Мне кажется во втором тезисе вы что-то перепутали)
А если подумали бы, то встроили бы в ОС свой родной язык программирования и среду разработки и… всё!
Напоминает MS + .NET + VS, как раз таки тот случай когда разработчики получили за это деньги.
Большинство альтернативных ОС, где разработчики просто выдают какое-то свое решение без родных языков и сред разработки, распространяется свободно.
Мне кажется во втором тезисе вы что-то перепутали)
В реальных конструкторских разработках, хотя бы, используются натурные и полунатурные эксперименты. А в программировании таких экспериментов нет.
Есть! — Вычислительные эксперименты, см. тут пример и ссылки на авторитетные источники.
Спасибо за ссылку. Однако, я имел в виду вариант прототипирования целых предприятий, чтобы иметь возможность «прокрутить» систему на полигоне. (Или Вы предлагаете что-то вроде «13-го этажа», то есть за полную симуляцию окружающего мира?)
Не важно целое предприятие или один станок с этого предприятия или один узел этого станка. Дело не в сложности. Эксперимент с деталью станка может быть сложнее. В приведенном примере дана игра — черный ящик и поставлена цель сделать программу-бота, взаимодействующего с этим ящиком в вычислительной среде, образующей полу-виртуальную реальность. Полу-виртуальную потому, что время, нпр., реальное. Если пойти путем мат.моделирования, то игра (прототип) заменяется программой-моделью, которая будет в некоторых важных нам случаях вести себя похоже. Остальные пути — работа непосредственно с прототипом, т.е. натурная. Могут быть использованы дополнительные вспомогательные средства контроля и созданы искусственные условия (аналог испытательного стенда) — тогда будет полу-натурная. В любом случае это экспериментальная работа в полном смысле этого слова. Один из измерительных приборов — секундомер (может быть внешний, а может таймер ОС).
Но, получается, что исправление ошибок проектирования выносится на этап эксплуатации.
Ошибка это когда есть несоответствие между тем "что есть" и тем "как надо". Вы исходите из неправильного предположения, что "как надо" никогда не меняется, и в процессе эксплуатации оно такое же как во время проектирования. Поэтому нет, не получается.
Вот это-то меня и беспокоит: когда меняется представление о том, «как надо». Если бы для каждого вида деятельности существовал некий стандарт, и все неукоснительно соблюдали бы выбранный стандарт, то разработчикам не надо было бы общаться с клиентами, а, просто, брать готовый стандарт и реализовывать именно его. Но, это так, мои мысли вслух, заметки, так сказать, на полях.
Если реальность расходится с вашими желаниями, это все равно не «ошибки проектирования».
Если бы для каждого вида деятельности существовал некий стандарт
Опишите стандарт на веб-сайт.
Возражаете, возражаете, а тут… Зачем кому-то мог бы понадобиться стандарт на сайт? Речь идёт о деятельности, которая не имеет никакого отношения к сайту. Если такой стандарт (на деятельность) есть, то что мешает запрограммировать его в виде компонента операционной системы? И зачем тогда нужен будет сайт? Нужен будет только поставщик данных и получатель данных.
Вы говорите, что в процессе жизненного цикла системы не должно быть доработок, что это ошибки проектирования, что нужен стандарт, по которому эту систему будут делать. И говорите, что если сделать по стандарту, то потом доработки будут не нужны.
Веб-сайт это система. В процессе его жизненного цикла в него вносятся доработки, потому что требования поменялись. Либо опишите стандарт, который учтет все возможные доработки, либо признайте, что доработки не являются ошибками проектирования.
И зачем тогда нужен будет сайт? Нужен будет только поставщик данных и получатель данных.
Веб-сайт это был пример системы. С целью чтобы вы задумались о том, почему невозможно то, что вы предлагаете. Ок, приведите стандарт на компонент операционной системы.
Ладно, возьмем пример попроще. Опишите стандарт на компонент комментария, реализовав который, можно будет не делать дальшейшие доработки во время жизненного цикла системы, где используются комментарии.
Да, стрельба очередями приносит свои плоды…
Вернёмся к началу Вашей реплики.
Теперь, вернёмся в конец и прочитаем следующую реплику в качестве постановки задачи:
Но это всё — тема большого разговора. Извините меня, пожалуйста, увлёкся. Больше не буду.
Веб-сайт это система«Холодно». Вы исходите из того, что есть сайт, и мы на него заходим. Я же исхожу из условий задачи и смотрю на это дело с противоположной стороны (я рассуждаю гипотетически, поэтому не навязываю своих правил): есть торговая система, а сайт — это просто некий узел доступа к этой системе. Для меня первичным является сама задача автоматизации торговли, и, если и может быть некий стандарт, то этот стандарт может быть связан именно с торговлей. По крайней мере, такой стандарт будет иметь смысл.
компонент операционной системыЧуть «теплее». Но и здесь не очень понятно, что именно требует стандартизации. Гораздо важнее вопрос: а что такое компонент? Чем должен являться компонент.
Опишите стандарт на компонент комментария, реализовав который, можно будет не делать дальшейшие доработки во время жизненного цикла системы, где используются комментарииВот это уже гораздо ближе к делу и составляет предмет моего теоретического интереса.
Вернёмся к началу Вашей реплики.
Веб-сайт это система. В процессе его жизненного цикла в него вносятся доработки, потому что требования поменялись.Требования к чему? К тому, какие данные и в каком виде отображать? К тому, как именно организовывать операции?
Либо опишите стандарт, который учтет все возможные доработки, либо признайте, что доработки не являются ошибками проектирования.Если бы (обратите внимание на эту важную оговорку «если бы»!) у нас был стандарт проведения операций (для определённой предметной области), то этот стандарт (единожды прописанный) мог бы быть один раз реализован без необходимости каких-либо доработок.
Вы говорите, что в процессе жизненного цикла системы не должно быть доработок, что это ошибки проектирования, что нужен стандарт, по которому эту систему будут делать. И говорите, что если сделать по стандарту, то потом доработки будут не нужны.Это не стандарт на производство программного обеспечения, это стандарт, в формализованном виде описывающий предметную область, модель предметной области. Весь вопрос в том, можно ли построить полную модель предметной области. Но если мы пытаемся строить такую модель, то мы, по моему скромному мнению, однажды придём к пониманию того, что такая модель должна быть органической частью операционной системы и использоваться для работы со всеми торговыми площадками, а сайты окажутся, в таком случае, простыми адресами для подключения к удалённому источнику/приёмнику данных. При такой «бизнес-модели», предприятия концентрируются исключительно на самой торговой деятельности, все IT-отделы на предприятиях упраздняются, остаются только грамотные OPS-ы, которые администрируют хранилища оперативных и аналитических данных, а то, как именно отображается информация и оформляется доступ к операциям, оставляется конечному пользователю.
Теперь, вернёмся в конец и прочитаем следующую реплику в качестве постановки задачи:
Опишите стандарт на компонент комментария, реализовав который, можно будет не делать дальшейшие доработки во время жизненного цикла системы, где используются комментарии.Мне кажется, что, если мы действительно хотели бы реализовать такой компонент, то нам потребовалось бы иметь достаточно высокий уровень абстракции в трёх точках: 1) в операционной системе должен быть справочник под условным названием «Номенклатура», где была бы позиция «Комментарий»; 2) в Интернете должно быть единое адресное пространство комментариев (чтобы каждый комментарий мог бы быть или был бы полноценным сайтом), чтобы на каждый можно было бы сослаться (как здесь, на Хабре; само слово hab нас «провоцирует»); 3) поддержка со стороны протокола. Проблема всякого проектирования, на мой взгляд, в том и заключается, что мы пытаемся сделать локальную версию того, что должно быть реализовано глобально. Системный подход это и означает: Вы не можете сделать что-то одно, если не сделаете что-то другое…
Но это всё — тема большого разговора. Извините меня, пожалуйста, увлёкся. Больше не буду.
Вы исходите из того, что есть сайт, и мы на него заходим. Я же исхожу из условий задачи
Для меня первичным является сама задача автоматизации торговли, и, если и может быть некий стандарт, то этот стандарт может быть связан именно с торговлей.
Омг. Еще раз повторю, веб-сайт — это пример, один из возможных, как и торговая система. Ладно, опишите стандарт на автоматизацию торговли, реализовав который, можно будет не делать доработки в процессе эксплуатации.
Требования к чему? К тому, какие данные и в каком виде отображать? К тому, как именно организовывать операции?
И данные, и отображение, и новые операции, и организация существующих, и производительность, и подключение новых сторонних систем, логи, мониторинг, безопасность...
Если бы у нас был стандарт проведения операций, то этот стандарт мог бы быть один раз реализован без необходимости каких-либо доработок.
Вот я и говорю, приведите пример такого стандарта. Он принципиально невозможен в виде, полностью исключающем доработки.
это стандарт, в формализованном виде описывающий предметную область, модель предметной области
И как из этого следует, что доработки не потребуются? Пример доработки — заказчик захотел поменять цвет кнопки "Купить" с синего на зеленый. Или передвинуть ее из девого угла в правый. Вы предлагаете это прописывать в стандарте предметной области?
Проблема всякого проектирования, на мой взгляд, в том и заключается, что мы пытаемся сделать локальную версию того, что должно быть реализовано глобально
Я об этом и попросил — опишите то, что предлагаете вы. Глобально значит глобально. Пункты 1,2,3 абсолютно ничего не говорят разработчику, который хочет добавить в систему комментарии, и уж тем более тому, кто будет делать эти справочники и протоколы.
Я согласен. Возможно, я сильно задумываюсь над тем, над чем не очень-то и следует задумываться. (Наверное, лучше всего, разработать и реализовать нечто реальное и осязаемое.) Но мне удаётся видеть ситуацию немножко не стой стороны, с которой это ожидается.
Вот, Вы пишете:
Короче! Если ставить задачу ребром: можно ли разрабатывать программное обеспечение таким образом, чтобы 1) по сети всегда передавались только данные (исключением может быть только удалённая установка программного обеспечения); 2) само программное обеспечение хранилось бы у пользователя на компьютере в базе данных и управлялось бы операционной системой; 3) поставщики данных и услуг были бы освобождены от вопросов создания диалоговых форм?
Представьте себе, что Вы — торговая фирма. Вы берёте, входите в Сеть и… регистрируйтесь… как торговая фирма. Ваши контрагенты в Сети уже есть: Вы их находите и присоединяете к себе. Для этого нужен некий Единый План Счетов, где каждая такая операция описывается как проводка по определённому счёту. Например: «Связать клиента А с фирмой Б». Это будет, очевидно, семантически нагруженная связь, а это значит, что сетевая инфраструктура должна реализовывать семантические сети в качестве одного из базовых протоколов. И что, при этом, будет требовать реализации? Только понятие объектов, узлов, связей между ними и ролей объектов. Заметьте, это всё очень напоминает идею «трансвключения», когда между различными документами Сети создаётся «живая» связь, позволяющая условно говоря, включить содержание одного документа в другой документ. Гиперссылка, которая изначально предполагалась именно для трансвключения, реализует только лишь простой переход между документами…
К чему приведёт такая организация дела? Например, к тому, что, во-первых, никогда не возникнет вопроса о первичных ключах и уникальных идентификаторах, во-вторых, легко единообразно применить любую форму отчётности, и, в-третьих, все бюджеты будут направлены на поддержание оперативной деятельности, а не на обслуживание оной. А чем издательская деятельность отличается от торговли? А образовательная? А проведение научных исследований? Везде можно найти аналоги складов, измерений, разрезов и всевозможных «счетов»! (Не хотите ли 1C в мировом масштабе?)))) А если суть происходящего укладывается в «прокрустово ложе» неких стандартных абстрактных объектов, операций и схем, то реализовывать нужно слой именно этой «абстракции». В качестве основного слоя представления для операционной системы. А уже все остальные задачи строить над ним.
Да. Универсального решения нет. Я и не предлагаю. Но думать над этим полезно. Может быть, кто-нибудь додумается, как это всё сделать. Когда-нибудь.
Вот, Вы пишете:
Пример доработки — заказчик захотел поменять цвет кнопки «Купить» с синего на зеленый. Или передвинуть ее из девого угла в правый. Вы предлагаете это прописывать в стандарте предметной области?У меня сразу же в такой ситуации возникает вопрос: а почему заказчика, вообще, интересует цвет кнопки и её местоположение на форме? Да, я понимаю, что заказчик заинтересован в хорошей подаче и хорошей отдаче. Но что будет, если оформление всегда будет определяться конечным пользователем, а заказчик будет только получать запросы на получение конкретных данных и отдавать такие конкретные данные?
Короче! Если ставить задачу ребром: можно ли разрабатывать программное обеспечение таким образом, чтобы 1) по сети всегда передавались только данные (исключением может быть только удалённая установка программного обеспечения); 2) само программное обеспечение хранилось бы у пользователя на компьютере в базе данных и управлялось бы операционной системой; 3) поставщики данных и услуг были бы освобождены от вопросов создания диалоговых форм?
Представьте себе, что Вы — торговая фирма. Вы берёте, входите в Сеть и… регистрируйтесь… как торговая фирма. Ваши контрагенты в Сети уже есть: Вы их находите и присоединяете к себе. Для этого нужен некий Единый План Счетов, где каждая такая операция описывается как проводка по определённому счёту. Например: «Связать клиента А с фирмой Б». Это будет, очевидно, семантически нагруженная связь, а это значит, что сетевая инфраструктура должна реализовывать семантические сети в качестве одного из базовых протоколов. И что, при этом, будет требовать реализации? Только понятие объектов, узлов, связей между ними и ролей объектов. Заметьте, это всё очень напоминает идею «трансвключения», когда между различными документами Сети создаётся «живая» связь, позволяющая условно говоря, включить содержание одного документа в другой документ. Гиперссылка, которая изначально предполагалась именно для трансвключения, реализует только лишь простой переход между документами…
К чему приведёт такая организация дела? Например, к тому, что, во-первых, никогда не возникнет вопроса о первичных ключах и уникальных идентификаторах, во-вторых, легко единообразно применить любую форму отчётности, и, в-третьих, все бюджеты будут направлены на поддержание оперативной деятельности, а не на обслуживание оной. А чем издательская деятельность отличается от торговли? А образовательная? А проведение научных исследований? Везде можно найти аналоги складов, измерений, разрезов и всевозможных «счетов»! (Не хотите ли 1C в мировом масштабе?)))) А если суть происходящего укладывается в «прокрустово ложе» неких стандартных абстрактных объектов, операций и схем, то реализовывать нужно слой именно этой «абстракции». В качестве основного слоя представления для операционной системы. А уже все остальные задачи строить над ним.
Да. Универсального решения нет. Я и не предлагаю. Но думать над этим полезно. Может быть, кто-нибудь додумается, как это всё сделать. Когда-нибудь.
Но что будет, если оформление всегда будет определяться конечным пользователем
Вы считаете, что миллионы не связанных с IT людей согласны получать сообщения вконтакте или ссылки на видео на ютубе через json, и сами расставлять кнопки и плееры писать? Что конкретно вы предлагаете?
можно ли разрабатывать программное обеспечение таким образом, чтобы
Нет. И я вам об этом сразу сказал, причем кажется еще где-то в другой статье. И если вы вместо того, чтобы спрашивать, подумаете, как именно это сделать, то поймете почему.
Представьте себе, что Вы — торговая фирма.
Не-не-не. Я уже привел пример с комментариями. Почему вы уходите от ответа?
а это значит, что сетевая инфраструктура должна реализовывать семантические сети в качестве одного из базовых протоколов.
Как именно она должна это реализовывать? Ваши расcуждения опираются на какие-то волшебные штуки "оно само так работает".
Например, к тому, что, во-первых, никогда не возникнет вопроса о первичных ключах и уникальных идентификаторах
Какой именно вопрос и почему его не будет в вашей схеме? Что в таком случае будет указано в той "нагруженной связи"?
Я и не предлагаю. Но думать над этим полезно.
Вот когда придумаете, тогда и будете говорить, что существующие подходы неправильные. Критикуешь — предлагай.
И если вы вместо того, чтобы спрашивать, подумаете, как именно это сделать, то поймете почему.Да, было бы очень заманчиво додумать мысль до конца и либо, всё-таки, сделать что-то осмысленное и предъявить сие благородному сообществу, либо признать ошибочность собственных посылок и представлений. В любом случае, вариант беспроигрышный.
Вот когда придумаете, тогда и будете говорить, что существующие подходы неправильные. Критикуешь — предлагай.Полностью подписываюсь под каждым Вашим словом. Засим, разрешите эту тему закрыть. (На перучёт.)))
Большое спасибо за внимание и долготерпение.
НЛО прилетело и опубликовало эту надпись здесь
А это хороший вопрос: как следует обучать программированию? Что является самом сложным в программировании? Наверное, самое сложное — это понять, что даже в простых случаях надо действовать с полной выкладкой. Разве проблемы проектирования (больших систем) не проистекают от того, что разработчики дали себе «слабину» ещё на этапе малых дел?
Наверное, самое сложное — это понять, что даже в простых случаях надо действовать с полной выкладкой
Да, программист должен отдавать себя всего своему делу, а ещё программист должен любить всем сердцем, переводить бабушек через дорогу, порхать как бабочка и жалить как оса.
Разве проблемы проектирования (больших систем) не проистекают от того, что разработчики дали себе «слабину» ещё на этапе малых дел?
Нет. Проблемы проектирования возникают обычно от того, что они не жалили как оса.
Довольно странный ответ. «С полной выкладкой» означает, что он должен выполнить все предписанные некоей неписанной методологией этапы. То есть, даже в простом случае, делать всё, что полагается делать в сложном случае. Чтобы не кусать локти, когда поезд уже ушёл. К тому же, многие большие приложения начинались с маленьких, поэтому в больших приложениях остаются все огрехи «туманной юности».
P.S. Если Вам не понятна реплика, спрашивайте, а не «минусуйте»: виноват, надо выражаться яснее. Но… юмор оценил.
P.S. Если Вам не понятна реплика, спрашивайте, а не «минусуйте»: виноват, надо выражаться яснее. Но… юмор оценил.
«С полной выкладкой» означает, что он должен выполнить все предписанные некоей неписанной методологией этапы
В том то и дело, что обычно нет. Если вы будете делать в простом случае всё, что полагается делать в сложном случае, вполне вероятно, что ваш продукт окажется просто неконкурентоспособным. Потому что пока вы будете делать красивую масштабируемую архитектуру, ваши конкуренты с написанным «по-быстренькому на коленке» продуктом будут делить рынок. А когда вы выйдете со своим запоздалым, но хорошим и отлаженным творением, у них уже будут деньги на развитие своих проектов, а у вас — нет. И они всегда будут на шаг впереди. Вы думаете, эти вот ребята
К тому же, многие большие приложения начинались с маленьких, поэтому в больших приложениях остаются все огрехи «туманной юности».
не знали, как писать софт «с полной выкладкой»? Пока вы продукт пишете, это здоровенная дыра в вашем кармане (или в кармане вашего инвестора), которая тянет и тянет ресурсы. Как только вы выходите на рынок, начинается обратный процесс. И для жизнеспособности проекта важнее, чтобы первый этап был намного короче. И обычно это намного важнее, чем заделы на будущее и правильное проектирование. Потому что если выход на рынок затянется, будущего может вообще не быть. А кривую архитектуру исправить в последующих версиях можно почти всегда. Равно как и много лет жить с костылями.
Вы всё правильно описываете. За исключением одной «малости»: за всё приходится платить, причём, далеко не сразу, и, часто совсем не тем, кто это всё затевал с самого начала. Быстрота выхода на рынок всегда оборачивается тем, что потом приходится тянуть тяжёлое наследие прошлого. Здесь получается крайне неприятная ситуация, когда по отдельности разные проекты показывают свою жизнеспособность (особенно на ранних этапах), а в целом для индустрии это оборачивается значительным торможением, когда сверх-короткий путь от идеи до реализации утверждает в индустрии подход, который вовсе не является наилучшим, просто, он был дороже всего продан.
(Однако, изначально, я смел виду гораздо более простой вариант «выкладки», когда мы формализуем все свои шаги, ничего не держим в голове, и делаем, даже, если делаем только для себя, делаем так, как если бы делали это для других.)
P.S. Могу привести один пример такого «технологического» решения, о котором мало говорят, если сказать, не говорят совсем, или, иногда, говорят слишком много. В своё время для кодировки символов стали использовать один байт. Это породило большую проблему кодировок. А теперь представьте, что, в своё время, разработчики специально задались бы вопросом: а как нам надо представлять символы? Можно ли признать решение в один байт хорошим решением? Нет, нельзя. А в четыре байта? А в восемь байтов? Вопрос, ведь, не в количестве байтов, хотя в стародавние времена экономический аспект был одним из важнейших, если не самый главный. Вопрос в архитектуре. Есть простые символы национальных алфавитов, есть диакритика. Есть управляющие символы с кодами (ASKII от 0 до 31), есть цифры, есть символы псевдографики. Всё это просто взяли и сложили в единый диапазон от 0 до 255. И что? Unicode решило эту проблему? Лишь, частично! А, теперь, представьте, каким был бы мир (от клавиатуры до компиляторов и офисных пакетов), если бы было найдено системное решение. Например, взяли бы и кодировали бы каждый символ тройками: <тип символа, номер символа, начертание символа> (надо бы это всё хорошенько продумать!). При этом, можно было бы организовать память таким образом, чтобы под каждый элемент тройки отводить своё количество байтов или битов. Это же можно было бы создать что-то вроде XML, только на самом низком уровне представления информации!
(Однако, изначально, я смел виду гораздо более простой вариант «выкладки», когда мы формализуем все свои шаги, ничего не держим в голове, и делаем, даже, если делаем только для себя, делаем так, как если бы делали это для других.)
P.S. Могу привести один пример такого «технологического» решения, о котором мало говорят, если сказать, не говорят совсем, или, иногда, говорят слишком много. В своё время для кодировки символов стали использовать один байт. Это породило большую проблему кодировок. А теперь представьте, что, в своё время, разработчики специально задались бы вопросом: а как нам надо представлять символы? Можно ли признать решение в один байт хорошим решением? Нет, нельзя. А в четыре байта? А в восемь байтов? Вопрос, ведь, не в количестве байтов, хотя в стародавние времена экономический аспект был одним из важнейших, если не самый главный. Вопрос в архитектуре. Есть простые символы национальных алфавитов, есть диакритика. Есть управляющие символы с кодами (ASKII от 0 до 31), есть цифры, есть символы псевдографики. Всё это просто взяли и сложили в единый диапазон от 0 до 255. И что? Unicode решило эту проблему? Лишь, частично! А, теперь, представьте, каким был бы мир (от клавиатуры до компиляторов и офисных пакетов), если бы было найдено системное решение. Например, взяли бы и кодировали бы каждый символ тройками: <тип символа, номер символа, начертание символа> (надо бы это всё хорошенько продумать!). При этом, можно было бы организовать память таким образом, чтобы под каждый элемент тройки отводить своё количество байтов или битов. Это же можно было бы создать что-то вроде XML, только на самом низком уровне представления информации!
Вы всё правильно описываете. За исключением одной «малости»: за всё приходится платить, причём, далеко не сразу, и, часто совсем не тем, кто это всё затевал с самого начала.
Верно. Но в большинстве случаев платить потом и больше, но когда проект раскручен — это намного проще, чем платить меньше сейчас, когда денег вообще нет.
А теперь представьте, что, в своё время, разработчики специально задались бы вопросом: а как нам надо представлять символы? Можно ли признать решение в один байт хорошим решением? Нет, нельзя.
Я могу не то, что представить, я могу уверенно утверждать, что они этим вопросом задавались. И знаете что? Оптимальным решением тогда было выбрано 7 бит. 128 возможных значений, это достаточно для всех знаков алфавита, цифр и ряда спецсимволов. Меньше современного байта, знаете ли. А потом, когда в моду вошли ЭВМ с восьмибитными байтами (на всякий случай отмечу, что байт — это не 8 бит, как часто говорят, а минимально адресуемый объем информации в ЭВМ, его размер зависит от архитектуры), это дало замечательную возможность локализовать их на разные языки.
А, теперь, представьте, каким был бы мир
Понимаете, Apple-II имела 4 килобайта ОЗУ в минимальной комплектации. Синклер — 16 килобайт. IBM PC — 64 килобайта, с возможностью расширения до 640К за кучу денег, PC XT — 256К, тоже с расширением до 640К. У программистов той эпохи стояла задача «как ещё ужать информацию», а не «а давайте раздуем текстовые константы в три раза, чтоб нашим детям через четверть века проще жилось». Поэтому решение с однобайтовым кодированием как раз отличный пример того, что всё должно быть своевременным.
Полностью подписываюсь под каждым Вашим словом. (Как, там, это называется? ПППКС?!?)))
Маленькое примечание. Когда появилась возможность использовать большие объёмы памяти, имело бы смысл делать новые компьютеры, и делать их на новых принципах. Но, поскольку, ничего этого сделано не было, всё, что мы имеем сегодня, суть наследие прошлого. Со всеми вытекающими.
Но системное решение заключается не в том, чтобы сразу дать под объект кучу битов или байтов («Бери пока дают!»), а в том, чтобы провести классификацию всех символов и найти для них оптимальное кодовое представление.
Маленькое примечание. Когда появилась возможность использовать большие объёмы памяти, имело бы смысл делать новые компьютеры, и делать их на новых принципах. Но, поскольку, ничего этого сделано не было, всё, что мы имеем сегодня, суть наследие прошлого. Со всеми вытекающими.
Но системное решение заключается не в том, чтобы сразу дать под объект кучу битов или байтов («Бери пока дают!»), а в том, чтобы провести классификацию всех символов и найти для них оптимальное кодовое представление.
НЛО прилетело и опубликовало эту надпись здесь
Это такой специальный тип статьи, чтобы срач в комментариях устроить? Замечательные аналогии просто на каждом шагу.
Почтил традиции Хабра — поговорил с переводом.
П.С.: Пока не понял о чем статья. Завтра дочитаю.
Много буков
Агась. В ВУЗах-то люди, которые специально приходят научаться, и то не все осиливают. А тут эвона как — любого научить можно.
Именно что сделало. Математиками и писателями. Нулевого уровня. Если дальше скилл не качать, то о лаврах Толстого мечтать глупо.
Нанимают не повара, а кухню. И дело тут не в качестве, а в количестве — один человек физически не сможет «снабдить» 20+ гостей к означенному часу _свежими_ блюдами.
В мире розовых коней — да. В реальном мире для сложного ПО с непростой предметной областью — разве что техлид имеет некоторое представление о картине в целом.
Вряд ли я один такой особенный, но у меня одним из первых вопросов идет «а что забыли включить в ТЗ? Может можно решить еще какие-то задачи с помощью программирования?»
Опять же в мире розовых коней. В мире победившего капитализма разработчик в первую очередь проверяет, работает ли ПО на железе/парке заказчика.
Тут мысль не совсем понятна. Я начинаю с поиска дыр еще на этапе составления/обсуждения ТЗ — «а что если на этом этапе юзер сделает Х, а не У (этот момент не обозначен в ТЗ, но возможен чисто теоретически)? Является ли такое развитие событий валидным сценарием?» и т.д.
Научить программировать можно любого — это легко
Агась. В ВУЗах-то люди, которые специально приходят научаться, и то не все осиливают. А тут эвона как — любого научить можно.
В школе нас обучили математике и письму, но это не сделало нас математиками и писателями.
Именно что сделало. Математиками и писателями. Нулевого уровня. Если дальше скилл не качать, то о лаврах Толстого мечтать глупо.
Большинство может легко научиться готовить...
Нанимают не повара, а кухню. И дело тут не в качестве, а в количестве — один человек физически не сможет «снабдить» 20+ гостей к означенному часу _свежими_ блюдами.
Разработчики ПО досконально изучают решаемые задачи, полностью понимают, как работают предложенные ими решения
В мире розовых коней — да. В реальном мире для сложного ПО с непростой предметной областью — разве что техлид имеет некоторое представление о картине в целом.
Прежде чем писать код, разработчик задастся следующими вопросами:
…
Как можно решить задачу, обойдясь без программирования?
Вряд ли я один такой особенный, но у меня одним из первых вопросов идет «а что забыли включить в ТЗ? Может можно решить еще какие-то задачи с помощью программирования?»
Когда разработчик пишет программу, он проверяет, чтобы она работала во множестве различных окружений, на машинах с разными ресурсами и в разных часовых поясах.
Опять же в мире розовых коней. В мире победившего капитализма разработчик в первую очередь проверяет, работает ли ПО на железе/парке заказчика.
Начинают с того, что называется сценарием по умолчанию
Тут мысль не совсем понятна. Я начинаю с поиска дыр еще на этапе составления/обсуждения ТЗ — «а что если на этом этапе юзер сделает Х, а не У (этот момент не обозначен в ТЗ, но возможен чисто теоретически)? Является ли такое развитие событий валидным сценарием?» и т.д.
Почтил традиции Хабра — поговорил с переводом.
П.С.: Пока не понял о чем статья. Завтра дочитаю.
Цитат Паскаля про письмо в оригинальной статье (ошибочно) приписано Марку Твену.
Я нахожу занятным тот факт, что переводчик потрудился проверить авторство.
Однако цитата, приписываемая Эйнштейну — скорее всего фольклор.
Дочитал статью, прочитал в оригинале. Много воды. Очень много воды. Суть Всей статьи может уместиться в одном абзаце:
Не надейтесь, что человек/команда без опыта создания большого ПО с нуля сделает качественное ПО. Даже если цена, названная этим человеком соблазнительно низка, скорее всего в итоге (даже если получите хоть как-то работающее ПО) вы потеряете сильно больше на этапе использования (плохие безопасность/поддержка/расширяемость/юзабилити).
Я нахожу занятным тот факт, что переводчик потрудился проверить авторство.
Однако цитата, приписываемая Эйнштейну — скорее всего фольклор.
Дочитал статью, прочитал в оригинале. Много воды. Очень много воды. Суть Всей статьи может уместиться в одном абзаце:
Не надейтесь, что человек/команда без опыта создания большого ПО с нуля сделает качественное ПО. Даже если цена, названная этим человеком соблазнительно низка, скорее всего в итоге (даже если получите хоть как-то работающее ПО) вы потеряете сильно больше на этапе использования (плохие безопасность/поддержка/расширяемость/юзабилити).
❶ Про статью. Вместо того чтобы использовать аналитический метод и сделать сравнительную таблицу по структуре и функциям «разработка» и «программирование», автор предпочёл формировать своё мнение на основе домыслов.
❷ Про термины. Да, действительно, термины меняются со временем, например в результате глупости оратора/писателя или применения им демагогии.
❸ Про комментарии. Информационно-ценные:
1. geher 01.11.17 в 13:21.
2. fatronix 02.11.17 в 10:35.
3. lxsmkv 01.11.17 в 21:30.
Остальные либо содержат грубые аналогии и обывательские формулировки, либо, как точно выразился fatronix 02.11.17 в 10:35, словоблудие.
❷ Про термины. Да, действительно, термины меняются со временем, например в результате глупости оратора/писателя или применения им демагогии.
❸ Про комментарии. Информационно-ценные:
1. geher 01.11.17 в 13:21.
2. fatronix 02.11.17 в 10:35.
3. lxsmkv 01.11.17 в 21:30.
Остальные либо содержат грубые аналогии и обывательские формулировки, либо, как точно выразился fatronix 02.11.17 в 10:35, словоблудие.
чем больше у программиста опыта, тем быстрее он создаст функциональное, точное, надежное решение, которое несложно будет поддерживать
Проблема определить, насколько правильный у программиста был опыт.
Понравилось. Ну, кроме, саморекламы.
Хорошо промыли мозги, потом рекламка своей компашки опытный разработчиков.
НЛО прилетело и опубликовало эту надпись здесь
Блез Паскаль
Разве честно вносить такие правки при переводе?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Не путайте разработку ПО и программирование