Не путайте разработку ПО и программирование

Автор оригинала: Samer Buna
  • Перевод

Каждый разработчик ПО умеет программировать, но не каждый программист может разрабатывать ПО



Большинство может легко научиться готовить, но когда нужно накормить большое число людей, мы нанимаем повара.

Возможно, кому-то больше нравится говорить не «разработчик», а инженер-программист, ведь инженер — это звучит гордо! Или нет? К счастью, эта статья не о терминах. Если мой термин вам не нравится — подставьте свой: «автор ПО», «мастер ПО»… и даже «творец приложений»!

Говоря «разработчик ПО», я имею в виду человека, для которого написание качественного ПО — профессия. Человека, который использует в своей работе научные подходы и статистику и считает свое занятие чем-то большим, чем просто зарабатывание денег.

Чтобы стать разработчиком, уметь программировать недостаточно.

Научить программировать можно любого — это легко. Писать простые программы, которые работают у конкретных людей на конкретных машинах, может почти кто угодно, но никто не гарантирует, что те же программы будут работать в других условиях.

Мне нравится такая аналогия: каждый может ради собственного развлечения петь в ду́ше, но вы же не ставите треки с записями этого пения на вечеринке — вы обращаетесь к произведениям профессиональных музыкантов.

Хотите еще аналогий? Пожалуйста:

  • В школе нас обучили математике и письму, но это не сделало нас математиками и писателями.
  • Большинство может легко научиться готовить, но когда нужно накормить большое число людей, мы нанимаем повара.
  • Никто не зовет соседа — мастера на все руки построить дом с нуля.

Главная задача этого текста — донести, что создание простых программ серьезно отличается от разработки ПО.

Переведено в Alconost

Программирование в простейшем представлении — это передача компьютеру указаний на совершение некоторых действия с некоторыми входными данными для получения некоторого вывода.

Разработка же программного обеспечения — это проектирование, написание, тестирование и поддержка компьютерных программ с целью решения задач для множества пользователей; это создание надежных защищенных решений, которые выдержат испытание временем и справятся с некоторыми не известными заранее задачами, лежащими в области, близкой к очевидным исходным задачам.

Разработчики ПО досконально изучают решаемые задачи, полностью понимают, как работают предложенные ими решения, как эти решения ограничены и как они характеризуются с точки зрения конфиденциальности работы с данными и безопасности.

А если кто-то не понимает задачу, ему нельзя давать разрабатывать для нее решение.

Ориентированный на решения подход


Разработчики ПО не считают своей работой просто написание программ — они рассуждают с точки зрения удовлетворения потребностей и решения задач. И это важно, потому что не для всякой задачи необходимо писать программу: в некоторых случаях достаточно использовать уже существующую программу или объединить несколько программ. А действуя на упреждение, иногда можно вообще избавиться от необходимости решать данную задачу: разработка хороших программ часто предполагает планирование, которое позволяет предупредить появление некоторых проблем и соответствующих задач в будущем.
«Умные решают проблемы — гении же их предотвращают».
— Альберт Эйнштейн


Для сложных задач приходится писать несколько программ. В некоторых случаях нужны программы, работающие параллельно, в других — запускающиеся последовательно. Иногда для решения задачи достаточно обучить пользователей.

Прежде чем писать код, разработчик задастся следующими вопросами:

  • Какие задачи я пытаюсь решить?
  • Как можно решить задачу, обойдясь без программирования?
  • Что можно сделать, чтобы писать код для решения задачи было проще?

Качество кода


В качественных программах код понятен и читается легко, их можно без труда расширять, они отлично взаимодействуют с другим ПО, а их поддержка не превращается в кошмар. Качество кода не должно становиться жертвой компромиссов; использование быстрых, но неаккуратных решений из-за поджимающего срока, излишнего волнения, взбудораженности, раздраженности и т. д. — неприемлемо.

Один из важнейших аспектов разработки ПО — это проектирование с нуля продукта, готового к расширению. Модификация приложений после их выпуска — факт, с которым нужно смириться. Пользователям будет нужно всё больше функционала, они захотят, чтобы пользоваться приложением было еще проще.

Компонент приложения обычно не очень полезен сам по себе. Пользу ПО начинает приносить, когда несколько компонентов взаимодействуют друг с другом, обмениваются данными и совместно работают на задачей представления данных и интерфейсов пользователям.
И с учетом этого нужно разрабатывать программы. Какие сообщения принимает ПО? Какие события отслеживает? Какие сообщения выдает? Как проходит проверка подлинности и авторизация при передаче данных?

Другой важный аспект написания хороших программ — это понятный код, а совсем не количество тестов или число в отчете о покрытии кода. Здесь всё просто. Подумайте: смогут ли другие прочитать код? Или — что еще лучше — сможете ли вы сами, написав код сегодня, понять его спустя несколько недель?
«В компьютерных технологиях есть только две сложные задачи: недействительность кэша и придумывание названий».
— Фил Карлтон

Читабельность кода имеет гораздо большее значение, чем может казаться. К сожалению, удобных показателей для оценки этой характеристики нет. Полезно будет запомнить зарекомендовавшие себя методики и шаблоны программирования, но часто этого недостаточно. У хорошего разработчика с опытом просто развивается интуиция, которая подсказывает, насколько читабелен код. Вот неплохое сравнение: чтобы писать лаконичный текст, недостаточно иметь большой словарный запас.
«У меня не было времени написать письмо короче».
— Блез Паскаль

С любой программой в какой-то момент что-то обязательно пойдет не так. Главный признак хорошего ПО — возможность легко исправить уже выпущенную в работу программу. Если программа во время работы выдает ошибку, об этом должно быть понятное сообщение, которое будет где-то централизованно записано — чтобы ошибки можно было отслеживать. При сообщении о новой ошибке у ответственного за ее исправление должна быть возможность провести отладку, в любой момент времени подключиться к системе и получить сведения о контексте выполнения, а также проверить ожидаемое поведение какого-либо компонента системы.



Рабочее окружение и тестирование


Когда разработчик пишет программу, он проверяет, чтобы она работала во множестве различных окружений, на машинах с разными ресурсами и в разных часовых поясах. ПО должно работать на экранах различных размеров и ориентации, в условиях ограниченной памяти и малой вычислительной мощности.

Например, если ПО пишется для веб-браузера, оно должно работать на всех основных браузерах. При создании классического ПО оно в большинстве случаев должно работать на платформах Mac и Windows. Если создаваемое приложение зависит от получения данных, оно должно продолжать работать и в том случае, если подключение к данным медленное или даже некоторое время полностью отсутствует.

Чтобы написать компонент ПО, разработчики пытаются продумать все возможные сценарии, которые только можно себе представить, и планируют их проверку. Начинают с того, что называется сценарием по умолчанию (или «счастливой дорогой» — от англ. «happy path»), в котором не происходит ничего неожиданного, а все возможные на этом пути проблемы — что важно — документируются и для каждой планируется тест. Некоторые разработчики начинают с написания «тестовых случаев», которые имитируют такие сценарии. Затем они пишут функциональный код, который проходит эти тестовые случаи.

Разработчики должны понимать предъявляемые к ПО требования, а ведь те часто бывают неоднозначными и неполными. Мастерство разработчика проявляется не в том, как он напишет решение, а скорее в том, какое решение он посчитает необходимым.

Стоимость и эффективность


В большинстве случаев разработчик может решить задачу быстро. Если вам кажется, что нанимать на работу опытных программистов — затратно, задумайтесь: чем больше у программиста опыта, тем быстрее он создаст функциональное, точное, надежное решение, которое несложно будет поддерживать. А это — меньшие затраты в долгосрочной перспективе.

Кроме того, учитывать следует и «стоимость работы» программы: всякое ПО потребляет ресурсы компьютера, а они не бесплатные. Разработчик напишет эффективную программу, которая не будет использовать ресурсы ПК без необходимости. Для этого он может применить, к примеру, кэширование часто используемых данных, — и это всего лишь один из, наверное, тысяч инструментов и способов, которые помогают повысить эффективность и скорость работы программы.

Возможно, программист-новичок и даст дешевое решение, но работа с этим решением может стоить вам и вашим клиентам намного больше, чем если бы вы сразу наняли опытного разработчика, который в первую очередь стремится найти эффективное решение.

Удобство использования


Хорошее ПО разрабатывается с учетом взаимодействия компьютера с пользователем (UX), и это довольно обширная тема, по которой проведено множество исследований и получено немало результатов. Чем больше выводов из этих исследований учтено, тем лучше будет ПО в использовании.

Позвольте я приведу пару примеров, чтобы вы могли прочувствовать, почему это важно:

  • Хорошо спроектированное ПО в формах ввода данных пользователей не будет учитывать регистр символов в поле электронной почты и удалит начальные и конечные пробелы. Не нужно усложнять пользователям жизнь из-за того, что у них включен CAPSLOCK: электронный адрес не зависит от регистра. Если программа принимает новые адреса электронной почты, проверяйте их заранее и понятным языком сообщайте пользователю, что он, возможно, ввел неправильный адрес. Здесь имеются в виду и банальные ошибки — например, отсутствие символа @, — и не столь очевидные: например, ошибочное написание популярного домена: «gmail.ocm».
  • Если пользователя нужно куда-либо перенаправить, хорошая программа запомнит исходный пункт и после выполнения необходимых действий вернет туда пользователя. Она запомнит и уже известные данные и взаимодействия, которые нужно связать с последующими шагами пользователя. Предположим, к примеру, что вы на сайте Expedia искали авиарейсы как гость, не входя в систему, — а затем решили создать учетную запись. Все предыдущие поисковые запросы в новой учетной записи сохранятся, и вы сможете ими воспользоваться с других машин.
  • Хорошее ПО разрабатывается с учетом реальных сценариев работы в ней пользователей. Нельзя просто добавлять какие-то функции — нужно поставить себя на место пользователя. На днях я бронировал рейс авиакомпании United Airlines и забыл добавить свой номер часто летающего пассажира. Получив подтверждение, я отправился на веб-сайт United Airlines, чтобы добавить этот номер в рейс, и это заняло у меня десять минут. Очевидного пути добавить этот номер не было, поэтому пришлось лазать по всем ссылкам, которые, как мне казалось, могли привести к нужному функционалу. Наконец я нашел нужную страницу: оказалось, что в прошлый раз я не заметил нужное поле, потому что оно было глубоко зарыто в большой форме. В итоге мне понадобилось отредактировать данные о пассажире, прокрутить на этой форме штук 20 полей ввода, выбрать нужный тип номера и обязательно ввести номер телефона — иначе форму отправить было нельзя. Это пример программы, которую мог бы разработать человек, не пытавшийся думать с точки зрения пользователя.

Надежность, безопасность и защищенность


Пожалуй, самый важный аспект, который отличает разработчиков-профессионалов от программистов-любителей, заключается в том, что профессионалы знают, что они несут ответственность за создание безопасных защищенных решений.

Компонент ПО должен быть устойчив к «плохим» данным, неправильным состояниям и неверному взаимодействию. Добиться такой устойчивости ОЧЕНЬ сложно — именно поэтому мы постоянно читаем о том, как кто-то умер из-за ошибки ПО.

Пользователи будут вводить в ПО «плохие» и неправильные данные. Кто-то будет делать это намеренно — с целью взломать ПО и добраться до ресурсов, которые представляет данное ПО. Сотрудника, якобы ответственного за брешь в безопасности американского бюро кредитных историй Equifax, которой воспользовались злоумышленники, обвинили в том, что он не выполнил свою работу: он должен был обеспечить устойчивость к «плохим» и вредоносным данным во всём ПО, открыто публикуемом от имени компании.

Задача обеспечения безопасности связана не только с «плохими» и вредоносными данными, но и с обычными. Например, если пользователь забыл пароль, сколько раз он может попробовать его ввести? Блокировать ли его после исчерпания попыток ввода? Что, если кто-то умышленно пытается заблокировать пользователя? Давать ли пользователям возможность отправлять пароль по незашифрованному соединению? Что делать, если кто-то пытается войти в учетную запись из необычного места? Что предпринять, если возникает подозрение, что вход в систему осуществляется автоматически?

Как защитить своих пользователей от межсайтовых сценариев и подделки межсайтовых запросов, атак «злоумышленник посередине» и простого социального фишинга? Как разработать стратегию резервного функционирования в случае DDoS-атаки на сервера? Перечисленные вопросы — лишь малая толика из множества вопросов, которые нужно учитывать при проектировании.

Защищенные программы хранят конфиденциальные сведения не в виде обычного текста, а как односторонне зашифрованные данные со сложно взламываемыми алгоритмами. Это — резервная защита на случай взлома ПО и несанкционированного доступа к данным: хакерам достанутся зашифрованные данные, которые в большинстве случаев будут бесполезны.

Приложение может перейти в состояние ошибки, и его нужно будет исправить: даже в самых лучших программах возникают неожиданные проблемы. Если вы не учитываете это при планировании, вы — не профессиональный разработчик, а просто кодер с небезопасными программами.

Программные дефекты выявить сложно. Наш ум ограничен в своей способности прогнозировать и предотвращать известные дефекты. Поэтому разработчики ПО ценят хорошие инструменты, которые помогают писать правильный код и создавать безопасное ПО.

Используемые инструменты


Очевидно, что нам нужно больше инструментов и нужны инструменты лучше. В разработке ПО инструменты имеют большое значение, но их часто недооценивают.

Представьте на минутку, что для развертывания нам по-прежнему нужно было бы использовать FTP! Представьте отладку сети и выявление проблем производительности без браузерных инструментов разработчика! Представьте себе, как упадет эффективность написания JavaScript-кода, если не использовать ESLint и Prettier!
Если в JavaScript-разработке вы почему-то вынуждены оставить только один плагин для редактора кода, выбирайте ESLint.

Отличным дополнением будет всякий инструмент, который сокращает цикл обратной связи при написании кода. Мысль Брета Виктора об изобретении мгновенных визуальных представлений того, что мы создаем, открыла мне глаза. Использование и совершенствование инструментов — один из способов приблизиться к этому светлому будущему. Если вы еще не видели выступление Брета — обязательно посмотрите его.

Когда я нахожу отличный инструмент, я сожалею лишь о том, что не пользовался им раньше. Чем лучше инструмент, тем лучше с его помощью пишутся программы. Ищите, используйте и цените их, а если можете — и совершенствуйте.

Выбор языка — важен. Безопасность типа — важна. Лучшее, что произошло с языком JavaScript, — это TypeScript (и Flow). Статический анализ кода важнее, чем вам кажется. Если вы его не используете, вы, в сущности, становитесь уязвимы для возможных неизвестных проблем в будущем. Не пишите код без системы статического контроля типов. Если в выбранном языке нет статического контроля типов, нужно либо сменить язык, либо найти для него транскомпилятор: сегодня они уже достаточно умны, чтобы работать по комментариям в коде, и мне кажется, что для языков, не поддерживающих статический контроль типов, транскомпиляторы вскоре станут стандартным инструментом.

Становление разработчика ПО


Невозможно научиться разрабатывать ПО за пару месяцев, полгода и даже за год. На курсах программирования из вас не сделают разработчика. Я начал учиться 20 лет назад — и продолжаю учиться сегодня. С достаточной уверенностью я смог назвать себя опытным программистом только после десяти лет обучения, в течение которых мне пришлось спроектировать, создать и обеспечить поддержку приложений, используемых тысячами пользователей.

Разработка программного обеспечения — занятие не для всех, но каждый должен научиться решать собственные задачи с помощью компьютеров. Если вы можете научиться писать простые программы — сделайте это. Если можете научиться использовать несложные программные сервисы — сделайте это. Если можете научиться использовать ПО с открытым исходным кодом, в ваших руках окажутся мощные инструменты.

Задачи с течением времени меняются, поэтому меняется и разработка ПО. Задача этой профессии в будущем — дать возможность обычным людям использовать компьютеры, не тратя при этом на обучение полдюжины лет. Нужно дать пользователям простые и понятные инструменты, с помощью которых они будут самостоятельно решать простые задачи. А затем разработчики перейдут к созданию лучших инструментов, решению более масштабных известных задач и сделают все возможное, чтобы предотвратить появление неизвестных проблем.


О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией игр, приложений и сайтов на 68 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Подробнее: https://alconost.com
Alconost
179,31
Локализуем на 70 языков, делаем видеоролики для IT
Поделиться публикацией

Комментарии 107

    +11

    Да, термины меняются со временем.


    Меня учили, что программирование состоит из следующих этапов:


    1. Анализ предметной области.
    2. Построение модели предметной области.
    3. Уточнение задач, которые необходимо решить в рамкмх предметной области (постановкой исходных задач явно или неявно занимается пользоаатель).
    4. Построение алгоритма решения задач, включая алгоритм взаимодейсьвия пользователя с программой или программным компоексом.
    5. Разработка архитектуры программы или программного комплекса, реализующего алгоритм.
    6. Реализация алгоритма в соответствии с выбоанной архитектурой в виде кода на языке программирования.
    7. Исправление ошибок, допущенных на всех этапах.
    8. Сборка программы или программного комплекса.

    Тестирование и реализация обратной саязи с пользователем к программированию уже не относится, но могут быть реализованы частично или полностью посредством программирования.
    А разработка ПО включает помимо программирования еще тестирование, организацию обратной связи, планирование рабочего времени, управление персоналом (даже если весь персонал — один человек).


    То же, что названо программированием, у нас называлось кодированием.

      +6
      Сначала дискредитировали кодеров, теперь общество желает крови несчастных программистов. Получается что программист — это плохой разработчик, а кодер — плохой программист.
      И судя по всему, если вы всего лишь разработчик, то вам рано расслабляться…
        0
        Зачем плодить сущности сверх необходимости?

        Есть номинальные понятия, связанные с тем, какую функцию выполняет человек в определённый момент времени. Есть определённые позиции или вакансии. Вопрос в том, что является результатом своего труда.

        Если результатом труда является программа, то речь идёт о программировании. В конце-концов, программа (в самом широком смысле) — это упорядоченная (в том числе, и во времени) совокупность предписаний, что и когда делать, позволяющая перевести систему из одного положения (полное отсутствие автоматизации) в другое (полная автоматизация всех бизнес-процессов).

        Роли, здесь, не играют… никакой роли.

        Хорошие программисты могут, конечно, между собою называть плохих программистов «кодерами», но особого смысла в этом нет. Другое дело, что в программировании для большинства программистов можно найти более продвинутых программистов, умеющих что-то ещё. В итоге, хороший программист — это тот прграммист, который знает, что ему всегда надо узнать что-то ещё. В этом смысле, все классификации заведомо слабы, поскольку никак не учитывают живую природу человека, который, если он не бездельник, завтра будет, уж точно не таким, как вчера.
        +9
        Это уж точно.
        Не путайте разработку ПО и программирование,
        Не путайте постройку домов и строительство,
        Не путайте написание книг и писательство…
          0
          Да. Всё это должно быть так. Но, к сожалению, так происходит не всегда. Часто один и тот же человек вынужден совмещать различные функции.

          Но, лучше не «спотыкаться о термины», а говорить о том, что можно и нужно писать хорошие программы, а можно (хотя и это неприемлемо) писать плохие. Можно расписать красивую структуру требований и подзадач, но ошибиться в анализе и промахнуться в реализации. Недаром, говориться «Семь раз отмерь...». Кто же просит программиста стразу резать? Никто. Только он сам.
          +1
          Да я полностью согласен с тем что создание простых программ серьезно отличается от разработки ПО.
          В любом случае, новичок, который решил стать опытным — программистом им в конце концов станет.

          Но вот что меня немного смущает так это то что автор проявляет интерес к разным направлениям разработки и делает вывод на этом буквально следующий, а именно то что если обычный программист занимается в течение 10 лет разработкой всего подряд, то он может худо да бедно назвать себя опытным, а если другой разработчик занимается только мобильной разработкой, то он ещё не разработчик ПО так что ли? (1-3 года опыта)

          Разработка программного обеспечения — занятие скорее относительно для всех кто действительно хочет и может этим заниматься.
          Программист – это больше чем профессия это проявление истинного творца сравнимое с самим богом. Создание (творения) своей формы жизни правда пока не совершенной к примеру ИИ, умное ПО – (Симуляция жизни) или просто обычное приложение — всё это и есть результат программирования.

          Как правило опыт может приобрестись быстро или медленно всё относительно того чем вы занимаетесь.
          Допустим вы достаточно компетентны в Front-end но у вас нет опыта в Back-end и это нормально, так как это не делает из вас не до программиста!
          Дело в том, что Программист учиться всю жизнь — но не программировать, а в покачивание своего Skill путём приобретения опыта в разработке!
            +3
            Попробую несогласиться с вами. Я начинал писать с GUI приложений, потом приложения двух-звенные с БД, чисто sql отчеты размерами несколько тысяч строк кода, потом веб-приложения с множеством модулей, сейчас чисто backend-микросервисы. Кроме того, чисто для себя изучал программирование микроконтроллеров, писал на железе вообще без ОС. И весь этот опыт позволяет мне думать обо всех этапах работы кода, вплоть о том, как мои данные передаются и по сети и почему они могут вызвать проблему OutOfMemory на сервере на ровном месте казалось бы.
            Недостаточно заниматься Front-End 10 лет и понимать при этом множество других аспектов. Это будет лишь «отличное понимаение как пишется Front-End». Автор скорее имел ввиду, что кто-то превосходно может разбираться в своей области, и это отлично, на самом деле, но недостаточно, чтобы предоставить возможность тому разработчику спроектировать новое приложение с нуля самостоятельно.
              +1
              Программист – это больше чем профессия это проявление истинного творца сравнимое с самим богом

              Дело в том, что Программист учиться всю жизнь

              Да куда там богам до программистов. Вы вон даже «бога» пишете с маленькой буквы, а «программиста» с большой.
              По-моему, для некоторых программистов в жизни куда важнее проблема, чтобы у них морда от ощущения собственной офигенности не разорвалась.
                0
                А теперь, внимание, вопрос: что будет, если, даже, создание простых программ (программ, решающих отдельные простые задачи) будет полноценной разработкой? Я усматриваю, здесь, корень проблемы. Если этого разделения не было бы, и мы относились с одинаковым вниманием к задачам различной сложности, то избежали бы множества ловушек и делали бы ПО высочайшего качества.

                Во-первых, в любую минуту может придти Некто, кто попросит даже в самом простом приложении прикрутить «вот эту фичу». Современные монструозные программы (ставшие целыми пакетами!) начинались с маленьких программок.

                Во-вторых, Вы всегда будете думать о том, что было бы, если бы у Вас была готовая инфраструктура для создания различных приложений, наличие которой гарантировало бы Вам определённый (высокий) уровень качества программного кода. Сколько было за последние 30 лет предложено всевозможных «фреймвёрков», многие из которых уже давно исчезли из обихода? А если бы эта инфраструктура была бы ещё и частью ОС?

                В-третьих, всегда возникает соблазн разбить большие приложения на маленькие. Зачем же мы создавали многофункциональное устройство, чтобы разрезать его на части? Может быть, было бы логичнее, иметь набор маленьких приложений, решающих маленькие задачи, и средство для сборки маленьких приложений для решения больших задач по требованию пользователя (в рамках ОС).

                Только, где мы найдём таких разработчиков, которые смогут выявить эти самые элементарные кирпичики и составить из них полноцветные мозаики? На этот вопрос статья ответа не даёт.
                +2
                Тема очень хороша и актуальна для текущего состояния отрасли IT, причем, если углубиться, обсасывается уже не один десяток лет. Шикарнейшая книга есть у Стива Макконнелла — «Профессиональная разработка программного обеспечения», где на протяжении всей книги сравнивается программист и инженер ПО. Инженерия говорит о зрелости отрасли, а эту зрелость обеспечивает очень и очень много факторов, и качество написания кода это хоть и важное, но только базовое качество которым должен обладать специалист-инженер.

                О зрелости стоит говорить вплоть до уровня качества инженерного образования в стране и уровня сертификации специалистов. Много ли вы знаете программистов с сертификатами? А ведь многие сервисы ее предоставляют (Zend, AWS, MySQL, т.п.). Многие если и получают их, то лишь для собственного удовлетворения. Нам до этого еще расти.

                Если вы инженер высокого уровня, то вы должны делать вклад не только в свой рабочий проект, но и в отрасль вцелом. Кто пишет книги по программированию, статьи, занимается разработкой новых технологий??? Многим из нас кажется, что этим должны заниматься Facebook и Google, но на самом деле этим должен заниматься каждый инженер высокого уровня, и это, собственно, один из показателей того, что вы инженер.

                Выступаете ли вы на конференциях с новыми решениями актуальных проблем, ходите ли вы на них чтобы узнать о том, с чем сталкиваются другие компании и их инженеры? Это обсуждение можно продолжать бесконечно, суть в том, что инженер это больше чем качественный программист, и нужно учиться мыслить глобальнее. Не только строчками своего кода, но и на уровне отрасли инженерии ПО вцелом.
                  +10
                  Лично мне кажется что тема надумана. Если я умею готовить и мне нужно приготовить на множество человек, то я не буду готовить только по двум причинам — 1) мне нужно заниматься чем-то ещё 2) я не умею готовить все блюда. Второе прямо говорит о том, что я не сформирован, как профессионал. И это не тот пример, когда школа не делает из на математиков, это когда первоклассник не в состоянии решить задачи выпускников. Тот разрыв, который демонстрируют на примере школы и математика, может выражаться лишь в различных профессиях, ведь создание ПО, это как аэропорт, где, естественно, все не лежит на плечах пилотов. ПО, это произведение которое играет оркестр, программирование, это написание произведения. И на примере этого. кажется что автор хочет сравнить оркестр с музыкантом.
                    –9
                    читать пост я конечно же не буду, но по картинке, очевидно, что аффтор не понимает о чем пишет
                      –4
                      Про повара хороший пример.

                      Я предпочитаю обедать дома, а не в супер-профессиональном ресторане Урюпинска или Москвы.

                      Дома — вкуснее.
                        0
                        Рассказывал своим сотрудникам практически то же.
                        Покажу, пускай почитают, может Хабру поверят)
                          –4
                          Недавно с друзьями рассуждали на тему «Программист, это творческая личность или нет?».
                          А как думаете Вы…?
                            –1
                            Думаю да, ибо как программист будет представлять себе прогу или что либо, так он ее и напишет, все равно что рисовать картину.
                              0

                              А это зависит от того, что это за программист.
                              Программист прекрасно может быть совсем не творческим ремесленником, который по стандартным правилам превращает ТЗ в код.
                              И программист может быть творческой личностью, творящей программный продукт, создающей его архитектуру не "по образцу и подобию", а как нечто новое, придумывающей новые приемы программирования, новые языки программирования или даже новые парадигмы программирования (насчет последнего, кажется, что уже все придумано: ООП, ФП и т.п., но чем черт не шутит, может быть, еще что-то изобретут).
                              И все это будет совершенно правильно именоваться "программирование".

                                –2
                                На Хабре нельзя ставить под вопрос элитизм которым овеяна личность человека стоящего по ту сторону информационных технологий. (с) Я.

                                Но, иронию в сторону. Я для себя пришел к выводу, после того как перевел один текст с английского на русский, что программирование это работа переводчика. Сделав перевод, я подправил его с учетом рекомендаций читателей. И в скоре даже забыл про что был текст.
                                кое-как нашел, вот
                                Пол Грэм: Как знать (How You Know)
                                habrahabr.ru/company/edison/blog/301666
                                Это просто рутинная работа. Порой мучительно сложная, но при определенном навыке перевести можно все.
                                Переводчик переводит с одного языка на другой. Программист — с человеческого языка на язык машины.
                                Романтики в этой профессии не больше чем в профессии переводчика. И творчества соответственно тоже. Переводчик может позволить себе удачный художественный оборот, чтобы выйти из положения когда прямой перевод невозможен. На этом пожалуй все «творчество» и заканчивается.

                                  +5
                                  Переводчик переводит с одного языка на другой. Программист — с человеческого языка на язык машины.

                                  Что за бред? Какой такой язык машины? Все что может машина — менять 0 на 1 разными способами. Это больше похоже, что переводчик переводит текст на язык ракушек, которые реагируют на наличие света или тени. И то аналогия далека от реальности.

                                    0
                                    я имею ввиду
                                    .doc (требования) -> .java (или любой другой понятный машине язык)

                                      +1

                                      Машина не понимает ничего, она не умеет думать

                                      –1
                                      Что за бред? Какой такой язык машины? Все что может машина — менять 0 на 1 разными способами

                                      Да, а всё, что может человек — это поглощать органические вещества, расщеплять их, и синтезировать другие, ну и получать при этом энергию. Тоже, знаете ли, не слишком много.
                                      Машина — это исполнитель. Она получает список команд из доступного ей набора и выполняет его. И скажите, вот например, солдат, который в общем случае умеет думать, но независимо от этого должен тупо выполнять команды командира подобно машине, он является аналогией компьютера? И если да, то переводчик, который переводит устав Красной Армии на немецкий язык, похож на программиста? ;)
                                        +1

                                        Вас вообще не в ту степь занесло. Солдат не может тупо ничего выполнять, командир дает приказ, который солдат должен осмыслить и интерпретировать. К примеру "Займи позицию в доме напротив". Для машины нужно что-то типа 500 шагов на 32 градуса северо-восток, развернуться спиной к дому, присесть и тд. Переводчик переводит мысли других людей, вот и все. Ему не нужно придумывать алгоритмы, состояния системы, знать как устроена машина и еще кучу всего, что обьязан знать и делать программист. Аналогия совершенно не подходит.

                                          0
                                          мне кажется все зацепились за слово переводчик, как профессию. Я же скорее имею ввиду переводчика как того, что переводит информацию из источника на язык получателя. И командир в таком случае, переводит информацию которую он получает о ситуации, в информацию (инструкции) для подчиненных, для выполнения задач.

                                          В «защиту» своей «аналогии» процитирую еще книжку
                                          «Решение задач на компьютерах» Москвитина А.А (с.320):

                                          Чтобы понять природу ошибок ( а это нам необходимо при переходе от неформального описания задачи пользователя к формальной реализации ее в виде программы) при переводе рассмотрим модель [...] Ha на ней человек осуществляет перевод информации из представления А в представление B.
                                          Может это более точное описание, той аналогии которую я имею ввиду.
                                            0
                                            мне кажется все зацепились за слово переводчик, как профессию

                                            Как увидел, так и прореагировал


                                            Романтики в этой профессии не больше чем в профессии переводчика. И творчества соответственно тоже. Переводчик может позволить себе удачный художественный оборот, чтобы выйти из положения когда прямой перевод невозможен. На этом пожалуй все «творчество» и заканчивается.
                                            0
                                            Переводчик переводит мысли других людей, вот и все.

                                            Не совсем так. «Человеческие» языки, если говорить о языках из разных групп, между собой отличаются очень сильно, не говоря уже о контексте, который понятен читателям И переводчик, если он не безмозглый подстрочник, это должен учитывать. Шутка про Пугачеву и Галкина в английском переводе должна превратиться в шутку про Хью и Кристал Хефнеров, а в арабском вообще исчезнуть или превратиться в шутку на другую тему.
                                            Для машины нужно что-то типа 500 шагов на 32 градуса северо-восток, развернуться спиной к дому, присесть и тд.

                                            Это лишь вопрос уровня абстракции. Современный программист ведь в подавляющем большинстве случаев работает с весьма высокоуровневыми библиотеками, и как раз отдает команды вида «займи позицию в доме напротив», понимая, что в библиотеке уже есть логика «зайти с заднего хода, закинуть гранату, потом под прикрывающим огнем заскочить и дать автоматную очередь». Да, её кто-то когда-то пошагово расписал, но это уже другая история.
                                              0

                                              Ему эти команды никто не расписывает. Тогда уже аналогия — из предложения "Хочу чтобы комментарии были на сайте" — написать роман с подробными шагами. Нету перевода, есть построение системы. "Хочу дом" — инженер его проектирует и строит, а не получил инструкции и перевел их в стены и двери.

                                        0
                                        В таком случае учитель это человек который переводит язык взрослых на язык детей, а доктор — человек который переводит крики пациента в язык движений скальпеля.
                                          0
                                          Про учителя в согласен, он переводит из ментальной модели взрослого в ментальную модель ребенка. Посредством например дидактической редукции. Доктор переводит из человеческого языка симптомов (тут болит) на формальный язык диагноза. И если заказчик (пациент) хочет это лечить врач предлагает известные ему методы избавления от симптомов и причин. (Что-то похожее на работу архитектора в айти). И передает работу хирургу, у кторого в конце концов на карточке написано что и где отрезать. Работа хирурга, практически не творческая. Но это все не значит что для этой работы не нужен талант. Талант нужен, чтобы свою функцию (ср. книги «Черновик», «Чистовик» у С. Лукьяненко) выполнять хорошо или лучше чем большинство других.
                                          Вы уж простите за такую «механистическую» перспективу. Это всего лишь взгляд под другим углом.
                                            0

                                            В работе хирурга тоже есть место творчеству.
                                            Что-нибудь отрезать можно разными способами.
                                            Пришить тоже.
                                            И эти способы нужно кому-то разрабатывать, а разработкой новых методов проведения операций занимаются обычно хирурги.

                                              0
                                              книги «Черновик», «Чистовик» у С. Лукьяненко

                                              Мне видится аналогия с более старой и ёмкой проблемой.
                                              кодер(хирург/функция) в большей степени следует алгоритмам (догмам/рекомендациям), а разработчик(инженер/руководитель/функционал) сам эти алгоритмы составляет. По моему мнению упомянутая книга как-бы и намекает, что если твоя функция в том, чтобы совершать выбор (и большой и маленький), то ты человек творческий, а разработка чего-либо — это без сомнения очень творческий вид деятельности.
                                              Вопрос в том, нужно ли стремится к тому чтобы стать творческим, или лучше уступить место другим?
                                            0
                                            Скорее не переводчик, а писатель или сценарист. «Напиши мне книжку про будущее и космические корабли на просторах Вселенной».
                                              0
                                              Переводчик переводит с одного языка на другой. Программист — с человеческого языка на язык машины.
                                              Забыли только, что программист иногда еще и алгоритм изобретает или адаптирует существующий под конкретную задачу. Что касается перевода с естественного языка на искусственный, то в общем случае такой перевод пока невозможен, кроме тривиальных случаев типа «два плюс два». Существующие искусственные языки даже теоретически не могут обеспечить многих соответствий с естественными. Но некоторым фантастам это не помешало выдумать, что в 22 веке все люди будут говорить на Алголе :))
                                                0
                                                вот, только что в комментариях к статье habrahabr.ru/post/341626 наткнулся:
                                                github.com/web-standards-ru/dictionary/issues/178 — работа переводчика тоже может заставлять его адаптировать и придумывать новое. Это нисколько не тривиальная и не рутинная работа. Но это ремесло. (просто многие программисты относятся к плодам своей работы с преувеличенным трепетом, а на самом деле можно к этому просто относиться как к переводу, перевел, отредактировал, сдал, приняли, отлично, нет, отредактировал второй раз, сдал, забыл)
                                                Однако и в дискуссии переводчиков (причем это однозначно технические переводчики, приобщенные к теме перевода) заметно напряжение, многополярность мнений, но в отличии от айтишников они никого за другое мнение не презирают, не оскорбляют, не минусуют, и не считают дураками, и в целом приветствуют эту дискуссиию.
                                                В них нет этого ничем не оправданного элитизма, который я упоминал в изначальном комментарии и который я надух не переношу. А так все хорошие ребята.
                                                  0
                                                  Давайте не будем валить в одну кучу этические моменты и объективные оценки характера той или иной работы. Работа переводчика не всегда ремесло, это может быть научная работа. Пример: перевод В.П. Козырева книги Ф. Харари, Теория графов, М.: Едиториал УРСС, 2003. Переводчик — опытный математик и в его предисловии к переводу приводятся ссылки на его научные работы, опубликованные в солидных изданиях. Заслугой перевода является более четкая терминология по сравнению с оригиналом. Сам автор отмечает проблему терминологии (С.22 перевода). Кроме того добавлено много комментариев переводчика, облегчающих понимание. Интересно почему я занялся таким сравнением? — очень просто: когда пишу статью в русскоязычное издание цитирую перевод, а когда в англоязычное — оригинал.

                                                  Давайте не будем забывать, что программирование это не чисто инженерная область, но и область науки CS (computer sci., переводят как информатика). У этой науки большое пересечение с математикой. А основой всех программ являются алгоритмы. Как и в каждой науке в CS много рутины, но это не делает ее ремеслом. Хотя и в любой другой науке встречаются ремесленники — пусть это будет их личной проблемой.
                                                    +1
                                                    Спасибо Вам за участие в обсуждении. Я эту дискуссию не ради базара начал, мне хочется понять, что делает этих людей особенными. Может мои наблюдения, на которых основаны, мои выводы однобоки. Потому что мне не с чем сравнить.

                                                    Мне, вобщем, не понятно, почему айтишники ставят себя всегда особняком. Ни одна инженерная профессия не порождает столько людей с завышеным самомнением, которые кичатся своими знаниями. Хотя в этой профессии нет ничего особенного. Ничего такого, что делало бы ее отличной от других профессий.
                                                    Вот когда программист начинает думать что его профессия — творческая, начинаются велосипеды и рвутся все дедлайны. Творческая работа скорее у программного архитектора.
                                                    А разработчик просто наполняет систему кодом. Как правило в сложных системах есть сложный фреймворк, но при этом каждый программист а пишет довольно простой код. Кладет свои кирпичи в раму. Но и тут находятся такие, которые кладут кирпичи поперек, поскольку ну раз нет спецификации, и никто не запрещает делать иначе, почему нет. Рама выложена кирпичами — чего тебе еще надо. Лишь бы сделать по-другому. Проявить свое творчество. Такие персонажи встречаются к сожалению. А может просто профессия засорена людьми без профильного образования.
                                                    В социальном плане эта профессиональная группа в основном состоит из крайностей. Или нерды-аутисты, или чуваки с синдромом Даннинга-Крюгера. Серединки маловато. У нас в команде из 20 человек «простых» ребят — меньше половины. К остальным, порой, не знаешь как подойти, чтобы не быть раздавленным их умственным превосходством. Не знаю с чем это связано, может и от возраста зависит.
                                                      0
                                                      И Вам спасибо за интересную постановку вопроса.

                                                      К остальным, порой, не знаешь как подойти, чтобы не быть раздавленным их умственным превосходством.


                                                      А здесь на Хабре разве Вас давят умственным превосходством? Посмотрел список Ваших недавних комментариев: показалось, что плюсов сильно больше, чем минусов.

                                                      У нас в команде из 20 человек


                                                      Довольно большая команда. Могут быть непростые взаимоотношения. Может дело в этом, а не в профессии?
                                                        0
                                                        Спасибо за ответ. Я тут еще раз подумал, и в купе с вашим замечанием, пришел к мысли, что вполне вероятно у меня просто искаженное восприятие. Просто у меня незаконченное айти образование, и скорее всего появился комплекс, из-за которого я слишком близко принимаю когда меня поправляют люди с большим опытом работы или знаниями. Или если я задаю какой-то вопрос, то мне кажется, что мне обьясняют категоричным надменным тоном, а на самом деле это просто мой комплекс приплетает подтекст которого нет. Надо будет понаблюдать за собой.
                                                          +1
                                                          По описанию похоже на фундаментальную ошибку атрибуции. В части про других.

                                                          P.S. На мой взгляд у вас чуть упрощённое представление о задачах программиста, однако качественно всё так и есть. Я бы просто сравнивал скорее с инженерно строительной областью. хотелки -> ТЗ -> эскиз -> архитектурный проект -> планы систем -> инструкции для рабочих. хотелки -> ТЗ -> концепция -> архитектура -> задание на компонент -> программа. И тут вопрос, что из этого входит в работу программиста.
                                                        0
                                                        Но и тут находятся такие, которые кладут кирпичи поперек, поскольку ну раз нет спецификации
                                                        К остальным, порой, не знаешь как подойти, чтобы не быть раздавленным их умственным превосходством

                                                        А как вы тогда определили, что поперек?) Можете примеры привести, может вы просто чего-то недопоняли?

                                                          0
                                                          Хорошо, вот коротенький пример:
                                                          внутренне система различает четыре статуса соединения, но для сторонних программных клиентов мы выдаем только два. Есть числовые константы обозначающие для программного клиента статус соединения сервиса. Интерфейс поддерживает метод проверки валидности переданного значения. Так вот, чтобы обозначить для клиента что значение на валидно, разработчик решил передавать статус соединения -1. Его нет в константах. Обьяснил тем, что на данный момент у нас только один программный клиент — это мы сами, и там они договорились с разработчиком что -1 это невалидное значение. А если появятся другие клиенты то можно с ними договориться.
                                                          Т.е. мы максимально неверно используем собственный интерфейс. Не используем метод проверки валидности значения, а используем незадекларированную константу.
                                                          Вот что про это можно сказать. У меня только полярная лисица приходин на ум.
                                                            +1
                                                            А вариант, что интерфейс спроектирован неправильно, вы не рассматриваете? Если обоим разработчикам удобнее использовать -1, значит надо поменять интерфейс.

                                                            Из описания не очень понятно, что куда передается, поэтому сложно сказать как будет правильно. Я представляю так.
                                                            В метод проверки валидности надо передавать результат вызова другого метода, например для установки соединения. Если там произошла ошибка, то логично возвращать -1. А собственно, какое значение предполагается возвращать (и проверять его валидность), если в константах нет значения обозначающего ошибку? К тому же вы предлагаете использовать 2 вызова вместо одного.
                                                              0
                                                              Данные о статусе передаются постоянно, и метод проверки валидности для того, чтобы отличать данные которые можно использовать, от тех которые нельзя. Возможно это сомнительный дизайн, но так сделано API передачи данных от системы к программным клиентам. Оно едино для всех системных компонент.
                                                              Я не знаю как правильно, я предлагаю придерживаться интерфейса. Я думаю, что если интерфейс будет в дальнейшем кем-то использоваться то, они будут работать с задекларированными константами. И получив -1 удивятся. Им придется звонить-писать нам, спрашивать в чем дело. Программист им обьяснит. Они договорятся. А можно ведь просто придерживаться интерфейса и не придется никому звонить. Вот и все. Так вот зачем эта самодеятельность. Чем она оправдана? Почему программист считает себя умнее архитектора? Вот что мне не понятно. Даже если он умнее архитектора, сделай как все делают, не переломишься ведь.
                                                              Вот возьмем работу какого нибудь мелкого гос-служащего, он же не ставит под вопрос недостатки процессов (лишние ненужные формуляры и т.п.), а просто выполняет ввереную ему работу. Но программист так не умеет.
                                                                +1

                                                                То есть с сервера на клиент постоянно идет поток данных? Ок, пусть так, откуда берутся значения, которые там передаются? Почему там может быть что-то отличное от констант и почему нельзя сразу передавать -1, а нужно передавать какие-то другие невалидные значения и потом их проверять?


                                                                Я не знаю как правильно

                                                                А программисты знают.


                                                                Я думаю, что если интерфейс будет в дальнейшем кем-то использоваться то, они будут работать с задекларированными константами. И получив -1 удивятся.

                                                                Ну так задекларируйте -1 в константах. Это же ваша система, и сторонних клиентов пока нет.


                                                                Так вот зачем эта самодеятельность. Чем она оправдана? Почему программист считает себя умнее архитектора?

                                                                Потому что он с этим каждый день работает. И сам в некоторой степени архитектор. А почему умнее-то? Он же не переделывал систему, а просто передает значение, это системой разрешено, он пользуется ее возможностями.


                                                                Кроме того. Вот есть метод, принимает на вход значение, возвращает валидность. Почему вы решили, что нужно обязательно использовать именно его именно в этой ситуации? Его сделали, чтобы проверять, когда валидность неизвестна. А если пришло -1, то валидность известна, и ничего проверять не надо. Вы предлагаете делать лишнюю работу… для чего? Почему нельзя просто сделать как удобнее всем?


                                                                Но программист так не умеет.

                                                                Так он и не гос-служащий. Он инженер и решает задачи.

                                                                  0
                                                                  клиент получает обьект с обновлением, и в нем содержится значение, и, используя метод проверки валидности, можно проверить валидность этого значения, т.е. можно этим значением пользоваться или нет. Например до полной калибровки системы значения невалидны и не должны отображаться.
                                                                  Так вот значения не обязательно числовые, поэтому я так думаю архитектор делал булевый метод который для любого переданного значения дает валидность этого значения. С другой стороны аргументы разработчика тоже понятны. Что делать тестировщику?
                                                                    +1
                                                                    Сказать «По документации должно быть 1 или 2, а у вас приходит -1, исправьте код или документацию» и отправить задачу разработчику.

                                                                    Все равно непонятно, какое значение должен отправлять сервер, если ни одна из текущих констант не подходит? Почему нельзя использовать -1?
                                                                      0
                                                                      ну сервер посылает 0 сервис не доступен, 1 сервис доступен, (хотя внутренне различает четыре состояния, но это клиента не интересует) При инициализации он шлет наружу 0, и то что значение не валидно. т.е. обрабатывать его рано. А в интепретации разработчика поскольку нет других клиентов, он сделал 0, 1 и -1 причем первые две задекларированы а третье значение нет. Ну вот и получается что получается, нужно будет рано или поздно переделывать.
                                                                      Вернувшись к аналогии с кирпичами, может это связано с тем, что как правило есть много поля для интерпретации в API, интерфейсах, документации. И соответственно там где нет четкого определения «правильно» разработчик включает мозги и делает свою интепретацию. Которая тоже не лишена смысла.
                                                                        0
                                                                        Если 0 это сервис недоступен, то что означает -1? Видимо это какая-то другая ситуация, не учтенная при проектировании.
                                                                          0
                                                                          -1 это в понимании разработчика комбинация 0 и valid=false. Просто он это выражает одним не задекларированным значением, и фронтэнд работает с этим значением. И у этой «парочки» (наш фронтэндер + наш разработчик) на данный момент все хорошо. Но этот же поток данных может использоваться без предупреждения и другими клиентами, на то это и интерфейс. И тогда будет мягко говоря неловкая ситуация…
                                                                          Вот и получается та ситуация которую я в частности критикую «я самый умный, я сделаю как я хочу и пофиг на всех остальных» и этому я не вижу никакого оправдания. Именно эта уверенность в своей правоте порой ошарашивает, нет бы хоть на минуту усомниться. Спросить архитектора или тех лида наконец.
                                                                          Но не исключено, что это еще и возрастное, как правило разрабы за 30 уже не страдают такой бескомпромиссностью и уверенностью.
                                                                          Или архитектор, может посмотреть на код и ляпнуть что-нибудь обидное в адрес разработчика. Зачем? Где коммуникационные навыки? Это тоже проявление ЧСВ. Можно ведь все тоже самое обьяснить нормально. Это поможет разработчику улучшить его навыки. А глупым оскорблением хорошего разработчика не воспитаешь. Вот и получается, что общаться между собой команда разработки практически не может, чтобы никогда никого не обижать. И вот о чем я говорю, что как мне кажется такое проявления ЧСВ — в особой мере присуще этой профессиональной группе.
                                                                          То что по отношению к заказчику все профессионалы бывают чсв-шными от сантехника до врача — это мы знаем. Но между собой. Вот что удивляет больше всего.
                                                                            +1
                                                                            -1 это в понимании разработчика комбинация 0 и valid=false.

                                                                            Хм, подождите, если состояние соединения = 0, то с использованием того специального метода нельзя получить valid = false, 0 ведь у вас присутствует в константах. То есть на валидность влияет что-то еще. О чем я и говорю — на практике появилась ситуация, не предусмотренная при проектировании.


                                                                            я самый умный, я сделаю как я хочу и пофиг на всех остальных

                                                                            Нет. Я инженер и сделаю так, как будет удобнее пользоваться, а также исправлю недочеты проектирования.


                                                                            Спросить архитектора или тех лида наконец.

                                                                            Они с этим кодом не работают. И видимо даже код-ревью не делают, иначе бы тех. лид увидел странные значения.
                                                                            А раз они код не контролируют, значит таким локальным архитектором выступает сам разработчик.


                                                                            Но этот же поток данных может использоваться без предупреждения и другими клиентами, на то это и интерфейс.

                                                                            А почему изменить-то его нельзя? Ведь и другим клиентам может быть удобнее использовать там -1.

                                                                0
                                                                так вот, я тестировщик, мне что делать? Как тестировать такой интерфейс. По имплементации программиста или использовать только те константы которые задекларированы в интерфейсе. Т.е с точки зрения стороннего клиента который ни про какие -1 не знает.
                                                                0
                                                                А почему метод должен возвращать именно константу, обозначающую статус соединения? Кажется, что метод проверки валидности переданного значения должен возвращать булевское (логическое) значение TRUE/FALSE, а статус соединения — это должен быть отдельный объект. Логика здесь такая: если соединение установлено некорректно, то у него не может быть какого-либо собственного внутреннего статуса.
                                                          +1
                                                          но в отличии от айтишников они

                                                          Ну так и программист это не переводчик. Инженер, аналитик, писатель. А переводчик это вон компилятор.


                                                          И да, на Хабре тоже много напряженных многополярных дискуссий, где высказывают аргументы и которые только приветствуются.

                                                          0
                                                          Не на Алголе, а на Логлане. %)
                                                      0
                                                      Научить программировать можно любого — это легко

                                                      Не соглашусь про легкость обучения программированию любого.

                                                      Недавно на хабре пролетала статья про это, но я нашел только несколько статей, про это. Краткое содержание этих статей: нет, программировать не легко, а повсеместные утверждения о том, что это легко, демотивируют начинающих программистов.
                                                        –1
                                                        Лучшее, что произошло с языком JavaScript, — это TypeScript (и Flow). Статический анализ кода важнее, чем вам кажется. Если вы его не используете, вы, в сущности, становитесь уязвимы для возможных неизвестных проблем в будущем. Не пишите код без системы статического контроля типов. Если в выбранном языке нет статического контроля типов, нужно либо сменить язык, либо найти для него транскомпилятор: сегодня они уже достаточно умны, чтобы работать по комментариям в коде, и мне кажется, что для языков, не поддерживающих статический контроль типов, транскомпиляторы вскоре станут стандартным инструментом.


                                                        — это догмат.

                                                        Есть другая точка зрения:

                                                        Алан Кей сказал:

                                                        Я не против типов, но я не знаю ни одной системы с типами, которая бы не вызвала мучений, так что я по-прежнему за динамическую типизацию»

                                                        Пока мы не придумаем, как по-настоящему нужно разрабатывать софт, выходом может быть создание динамических систем с экстремально поздним связыванием во всех его проявлениях

                                                        Позднее связывание позволяет воплощать идеи на поздних стадиях разработки с экспоненциально меньшими усилиями чем традиционное раннее связывание как в C, С++, Java и прочих похожих языках

                                                        Если вы используете язык с ранним связыванием, как делает большинство людей, вместо языка с поздним связыванием, вы окажетесь взаперти у проделанной работы. Переформулировать что-то будет уже непросто


                                                        Тот кто ругает ЖаваСкрипт просто не понимает его прелесть, его смысл.
                                                        ЖаваСкрипт прекрасен, это вершина развития программирования, это как бы Лисп в шкуре Си.

                                                        Лисп и Си это самые крутые классические языки. Ну еще Пролог и Логлан можно выделить.

                                                        ЖаваСкрипт прекрасен тем что его можно освоить за один день: habrahabr.ru/post/332574

                                                          0
                                                          Поддерживаю, особенно после The Shocking Secret About Static Types.
                                                            +1
                                                            Если бы статические системы типов ограничивались лишь джавой или плюсами, то в таком мире и я бы жить не захотел. К счастью, есть более адекватные языки семейства ML.
                                                              0
                                                              В JS нет макросов, так что это далеко не лисп.
                                                                0
                                                                Ты не уловил смысл — максимальный минимализм.
                                                                Чем проще язык тем лучше.

                                                                Минимальная сложность при максимальных возможностях.
                                                                Поэтому JS похож качеством дизайна на Лисп и Си.

                                                                Синтаксис языка JavaScript во многом напоминает синтаксис Си и Java, семантически же язык гораздо ближе к Self, Smalltalk или даже Лиспу


                                                                Я например использую только 50 элементов языка JS и 50 элементов языка CSS.
                                                                Эти языки в виде простого подмножества можно освоить за день.
                                                                  0
                                                                  От твоего комментария макросы в JS всё равно не появились. :P
                                                                    0
                                                                    Ты наверное слишком умный ))
                                                                    Я не понимаю зачем это бывает нужно, и как я без этого программирую.
                                                                      +1
                                                                      Тогда зачем тебе лисп?
                                                                    0
                                                                    > Поэтому JS похож качеством дизайна на Лисп и Си.

                                                                    Это в JS минимальная сложность? JS объективно сложнее по своей семантике, чем тот же си. И просто на порядок сложнее джавы.
                                                                +2

                                                                Коллеги, ИМХО перевод цитаты не совсем корректен:


                                                                "В компьютерных технологиях есть только две сложные задачи: недействительность кэша и придумывание названий"

                                                                — правильнее было бы "инвалидация кэша" (процесс + конкретный термин, не нуждающий в "русификации") и "придумывание имен" (более общая и частая задача — имена функций, классов и тп)

                                                                  0

                                                                  "именование" гораздо лучше и ёмче.

                                                                  +1
                                                                  В некоторых общественных столовых такую дрянь готовят, даже я приготовлю лучше. И при этом не стыдятся называть себя поварами…

                                                                  Аналогично некоторые сервисы так дряно работают, все виснет, проводится в ручном режиме, нет нужного функционала. Но как то работает, люди туда приходят.

                                                                  Так что не соглашусь. Если припрет и умеете готовить — сможете приготовить и котел жратвы на 100 чел. Может и не похвалят, но с голоду не помрут.
                                                                    0
                                                                    Каждый разработчик ПО умеет программировать
                                                                    И сразу нет. :) Взять любой средний-большой игрострой (да и инди сойдет, если там больше 1 каски) — там есть дизайнеры, художники, моделлеры, музыканты. Это разработчики? Да. Умеют они погромировать? Нет. :)
                                                                      +2
                                                                      Главная задача этого текста — донести, что создание простых программ серьезно отличается от разработки ПО


                                                                      Открыли Америку! Создание простых программ серьезно отличается от создания сложных программ! А создание сложных программ серьезно отличается от разработки ПО?

                                                                      Разработчики ПО досконально изучают решаемые задачи, полностью понимают, как работают предложенные ими решения


                                                                      Как быть с эвристическими алгоритмами? Они работают, но никто не может полностью понять, как они это делают… М.б. в разработке ПО такие алгоритмы не применяют? ;)

                                                                      Разработчики ПО не считают своей работой просто написание программ — они рассуждают с точки зрения удовлетворения потребностей и решения задач. И это важно, потому что не для всякой задачи необходимо писать программу: в некоторых случаях достаточно использовать уже существующую программу


                                                                      Человек, предложивший уже существующую программу — это разработчик ПО? Прихожу в магазин, прошу ОС или текстовый редактор, продавец выкладывает мне диски и коробки — он разработчик ПО! :)

                                                                      У меня больше нет слов… нужна перезагрузка…
                                                                        +1
                                                                        Человек, предложивший уже существующую программу — это разработчик ПО? Прихожу в магазин, прошу ОС или текстовый редактор, продавец выкладывает мне диски и коробки — он разработчик ПО! :)

                                                                        Полагаю, что автор имел ввиду всего лишь повторное использование кода или программ в новом проекте. Например, разработчику IDE. нет нужды писать новый компилятор, и его можно взять готовым.
                                                                        Но что получилось, то получилось.

                                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                                          0
                                                                          Весьма вторичный материал.
                                                                          Примерно те же мысли излагает Ф. Брукс в начале «Мифического человеко-месяца» приводя отличия «программы созданной программистами в гараже» от «системного программного продукта создаваемого промышленной командой».
                                                                            0
                                                                            А, разве, со временем отличия не скрадываются? Не получается так, что промышленная команда (в погоне за гибкостью или, наоборот, за системностью) начинает походить на «гаражного программиста»? Когда какая-то промышленным образом разработанная система требует постоянной доработки, то, просто, мало кто воспринимает это негативно. Как можно выпустить «сырой» программный продукт? Это, конечно, сильный ход — сделать доработку частью жизненного цикла системы. Но, получается, что исправление ошибок проектирования выносится на этап эксплуатации. В реальных конструкторских разработках, хотя бы, используются натурные и полунатурные эксперименты. А в программировании таких экспериментов нет. Всё по живому.

                                                                            И ещё один момент, который мало кто учитывает. Реальные приложения — это некие «конструкции», которые возведены над ОС и другими «конструкциями». Строго говоря, нельзя возвести хорошее здание без хорошего фундамента. Но программисты всегда пользуются тем, что есть. А Вы попробуйте поставить вопрос: как должна выглядеть ОС, чтобы мы писали эффективные приложения? Но тогда выяснится, что разработчики ОС просто выдали какое-то своё решение и получили за это свои деньги, а как им будут пользоваться, не подумали: продали — и ладно. А если подумали бы, то встроили бы в ОС свой родной язык программирования и среду разработки и… всё!
                                                                              0
                                                                              Если со временем профессионалы начинают в погоне за чем-либо нарушать промышленные стандарты, то это говорит о деградации процессов. Причины могут быть разные, в т.ч. и давление со стороны маркетинга или менеджмента в погоне за скорейшей прибылью, как вы выразились. Это печально. Но время всё расставит по своим местам.

                                                                              А если подумали бы, то встроили бы в ОС свой родной язык программирования и среду разработки и… всё!

                                                                              Напоминает MS + .NET + VS, как раз таки тот случай когда разработчики получили за это деньги.

                                                                              Большинство альтернативных ОС, где разработчики просто выдают какое-то свое решение без родных языков и сред разработки, распространяется свободно.

                                                                              Мне кажется во втором тезисе вы что-то перепутали)
                                                                                0
                                                                                Мне кажется во втором тезисе вы что-то перепутали)
                                                                                Возможно. На истину в последней инстанции не претендую. Просто, мысли вслух.
                                                                                0
                                                                                В реальных конструкторских разработках, хотя бы, используются натурные и полунатурные эксперименты. А в программировании таких экспериментов нет.


                                                                                Есть! — Вычислительные эксперименты, см. тут пример и ссылки на авторитетные источники.
                                                                                  0
                                                                                  Спасибо за ссылку. Однако, я имел в виду вариант прототипирования целых предприятий, чтобы иметь возможность «прокрутить» систему на полигоне. (Или Вы предлагаете что-то вроде «13-го этажа», то есть за полную симуляцию окружающего мира?)
                                                                                    0
                                                                                    Не важно целое предприятие или один станок с этого предприятия или один узел этого станка. Дело не в сложности. Эксперимент с деталью станка может быть сложнее. В приведенном примере дана игра — черный ящик и поставлена цель сделать программу-бота, взаимодействующего с этим ящиком в вычислительной среде, образующей полу-виртуальную реальность. Полу-виртуальную потому, что время, нпр., реальное. Если пойти путем мат.моделирования, то игра (прототип) заменяется программой-моделью, которая будет в некоторых важных нам случаях вести себя похоже. Остальные пути — работа непосредственно с прототипом, т.е. натурная. Могут быть использованы дополнительные вспомогательные средства контроля и созданы искусственные условия (аналог испытательного стенда) — тогда будет полу-натурная. В любом случае это экспериментальная работа в полном смысле этого слова. Один из измерительных приборов — секундомер (может быть внешний, а может таймер ОС).
                                                                                  0
                                                                                  Но, получается, что исправление ошибок проектирования выносится на этап эксплуатации.

                                                                                  Ошибка это когда есть несоответствие между тем "что есть" и тем "как надо". Вы исходите из неправильного предположения, что "как надо" никогда не меняется, и в процессе эксплуатации оно такое же как во время проектирования. Поэтому нет, не получается.

                                                                                    0
                                                                                    Вот это-то меня и беспокоит: когда меняется представление о том, «как надо». Если бы для каждого вида деятельности существовал некий стандарт, и все неукоснительно соблюдали бы выбранный стандарт, то разработчикам не надо было бы общаться с клиентами, а, просто, брать готовый стандарт и реализовывать именно его. Но, это так, мои мысли вслух, заметки, так сказать, на полях.
                                                                                      0
                                                                                      Если реальность расходится с вашими желаниями, это все равно не «ошибки проектирования».
                                                                                        0
                                                                                        Если бы для каждого вида деятельности существовал некий стандарт

                                                                                        Опишите стандарт на веб-сайт.

                                                                                          0
                                                                                          Возражаете, возражаете, а тут… Зачем кому-то мог бы понадобиться стандарт на сайт? Речь идёт о деятельности, которая не имеет никакого отношения к сайту. Если такой стандарт (на деятельность) есть, то что мешает запрограммировать его в виде компонента операционной системы? И зачем тогда нужен будет сайт? Нужен будет только поставщик данных и получатель данных.
                                                                                            0

                                                                                            Вы говорите, что в процессе жизненного цикла системы не должно быть доработок, что это ошибки проектирования, что нужен стандарт, по которому эту систему будут делать. И говорите, что если сделать по стандарту, то потом доработки будут не нужны.


                                                                                            Веб-сайт это система. В процессе его жизненного цикла в него вносятся доработки, потому что требования поменялись. Либо опишите стандарт, который учтет все возможные доработки, либо признайте, что доработки не являются ошибками проектирования.


                                                                                            И зачем тогда нужен будет сайт? Нужен будет только поставщик данных и получатель данных.

                                                                                            Веб-сайт это был пример системы. С целью чтобы вы задумались о том, почему невозможно то, что вы предлагаете. Ок, приведите стандарт на компонент операционной системы.


                                                                                            Ладно, возьмем пример попроще. Опишите стандарт на компонент комментария, реализовав который, можно будет не делать дальшейшие доработки во время жизненного цикла системы, где используются комментарии.

                                                                                              0
                                                                                              Да, стрельба очередями приносит свои плоды…
                                                                                              Веб-сайт это система
                                                                                              «Холодно». Вы исходите из того, что есть сайт, и мы на него заходим. Я же исхожу из условий задачи и смотрю на это дело с противоположной стороны (я рассуждаю гипотетически, поэтому не навязываю своих правил): есть торговая система, а сайт — это просто некий узел доступа к этой системе. Для меня первичным является сама задача автоматизации торговли, и, если и может быть некий стандарт, то этот стандарт может быть связан именно с торговлей. По крайней мере, такой стандарт будет иметь смысл.
                                                                                              компонент операционной системы
                                                                                              Чуть «теплее». Но и здесь не очень понятно, что именно требует стандартизации. Гораздо важнее вопрос: а что такое компонент? Чем должен являться компонент.
                                                                                              Опишите стандарт на компонент комментария, реализовав который, можно будет не делать дальшейшие доработки во время жизненного цикла системы, где используются комментарии
                                                                                              Вот это уже гораздо ближе к делу и составляет предмет моего теоретического интереса.

                                                                                              Вернёмся к началу Вашей реплики.
                                                                                              Веб-сайт это система. В процессе его жизненного цикла в него вносятся доработки, потому что требования поменялись.
                                                                                              Требования к чему? К тому, какие данные и в каком виде отображать? К тому, как именно организовывать операции?
                                                                                              Либо опишите стандарт, который учтет все возможные доработки, либо признайте, что доработки не являются ошибками проектирования.
                                                                                              Если бы (обратите внимание на эту важную оговорку «если бы»!) у нас был стандарт проведения операций (для определённой предметной области), то этот стандарт (единожды прописанный) мог бы быть один раз реализован без необходимости каких-либо доработок.
                                                                                              Вы говорите, что в процессе жизненного цикла системы не должно быть доработок, что это ошибки проектирования, что нужен стандарт, по которому эту систему будут делать. И говорите, что если сделать по стандарту, то потом доработки будут не нужны.
                                                                                              Это не стандарт на производство программного обеспечения, это стандарт, в формализованном виде описывающий предметную область, модель предметной области. Весь вопрос в том, можно ли построить полную модель предметной области. Но если мы пытаемся строить такую модель, то мы, по моему скромному мнению, однажды придём к пониманию того, что такая модель должна быть органической частью операционной системы и использоваться для работы со всеми торговыми площадками, а сайты окажутся, в таком случае, простыми адресами для подключения к удалённому источнику/приёмнику данных. При такой «бизнес-модели», предприятия концентрируются исключительно на самой торговой деятельности, все IT-отделы на предприятиях упраздняются, остаются только грамотные OPS-ы, которые администрируют хранилища оперативных и аналитических данных, а то, как именно отображается информация и оформляется доступ к операциям, оставляется конечному пользователю.

                                                                                              Теперь, вернёмся в конец и прочитаем следующую реплику в качестве постановки задачи:
                                                                                              Опишите стандарт на компонент комментария, реализовав который, можно будет не делать дальшейшие доработки во время жизненного цикла системы, где используются комментарии.
                                                                                              Мне кажется, что, если мы действительно хотели бы реализовать такой компонент, то нам потребовалось бы иметь достаточно высокий уровень абстракции в трёх точках: 1) в операционной системе должен быть справочник под условным названием «Номенклатура», где была бы позиция «Комментарий»; 2) в Интернете должно быть единое адресное пространство комментариев (чтобы каждый комментарий мог бы быть или был бы полноценным сайтом), чтобы на каждый можно было бы сослаться (как здесь, на Хабре; само слово hab нас «провоцирует»); 3) поддержка со стороны протокола. Проблема всякого проектирования, на мой взгляд, в том и заключается, что мы пытаемся сделать локальную версию того, что должно быть реализовано глобально. Системный подход это и означает: Вы не можете сделать что-то одно, если не сделаете что-то другое…

                                                                                              Но это всё — тема большого разговора. Извините меня, пожалуйста, увлёкся. Больше не буду.
                                                                                                0
                                                                                                Вы исходите из того, что есть сайт, и мы на него заходим. Я же исхожу из условий задачи
                                                                                                Для меня первичным является сама задача автоматизации торговли, и, если и может быть некий стандарт, то этот стандарт может быть связан именно с торговлей.

                                                                                                Омг. Еще раз повторю, веб-сайт — это пример, один из возможных, как и торговая система. Ладно, опишите стандарт на автоматизацию торговли, реализовав который, можно будет не делать доработки в процессе эксплуатации.


                                                                                                Требования к чему? К тому, какие данные и в каком виде отображать? К тому, как именно организовывать операции?

                                                                                                И данные, и отображение, и новые операции, и организация существующих, и производительность, и подключение новых сторонних систем, логи, мониторинг, безопасность...


                                                                                                Если бы у нас был стандарт проведения операций, то этот стандарт мог бы быть один раз реализован без необходимости каких-либо доработок.

                                                                                                Вот я и говорю, приведите пример такого стандарта. Он принципиально невозможен в виде, полностью исключающем доработки.


                                                                                                это стандарт, в формализованном виде описывающий предметную область, модель предметной области

                                                                                                И как из этого следует, что доработки не потребуются? Пример доработки — заказчик захотел поменять цвет кнопки "Купить" с синего на зеленый. Или передвинуть ее из девого угла в правый. Вы предлагаете это прописывать в стандарте предметной области?


                                                                                                Проблема всякого проектирования, на мой взгляд, в том и заключается, что мы пытаемся сделать локальную версию того, что должно быть реализовано глобально

                                                                                                Я об этом и попросил — опишите то, что предлагаете вы. Глобально значит глобально. Пункты 1,2,3 абсолютно ничего не говорят разработчику, который хочет добавить в систему комментарии, и уж тем более тому, кто будет делать эти справочники и протоколы.

                                                                                                  0
                                                                                                  Я согласен. Возможно, я сильно задумываюсь над тем, над чем не очень-то и следует задумываться. (Наверное, лучше всего, разработать и реализовать нечто реальное и осязаемое.) Но мне удаётся видеть ситуацию немножко не стой стороны, с которой это ожидается.

                                                                                                  Вот, Вы пишете:
                                                                                                  Пример доработки — заказчик захотел поменять цвет кнопки «Купить» с синего на зеленый. Или передвинуть ее из девого угла в правый. Вы предлагаете это прописывать в стандарте предметной области?
                                                                                                  У меня сразу же в такой ситуации возникает вопрос: а почему заказчика, вообще, интересует цвет кнопки и её местоположение на форме? Да, я понимаю, что заказчик заинтересован в хорошей подаче и хорошей отдаче. Но что будет, если оформление всегда будет определяться конечным пользователем, а заказчик будет только получать запросы на получение конкретных данных и отдавать такие конкретные данные?

                                                                                                  Короче! Если ставить задачу ребром: можно ли разрабатывать программное обеспечение таким образом, чтобы 1) по сети всегда передавались только данные (исключением может быть только удалённая установка программного обеспечения); 2) само программное обеспечение хранилось бы у пользователя на компьютере в базе данных и управлялось бы операционной системой; 3) поставщики данных и услуг были бы освобождены от вопросов создания диалоговых форм?

                                                                                                  Представьте себе, что Вы — торговая фирма. Вы берёте, входите в Сеть и… регистрируйтесь… как торговая фирма. Ваши контрагенты в Сети уже есть: Вы их находите и присоединяете к себе. Для этого нужен некий Единый План Счетов, где каждая такая операция описывается как проводка по определённому счёту. Например: «Связать клиента А с фирмой Б». Это будет, очевидно, семантически нагруженная связь, а это значит, что сетевая инфраструктура должна реализовывать семантические сети в качестве одного из базовых протоколов. И что, при этом, будет требовать реализации? Только понятие объектов, узлов, связей между ними и ролей объектов. Заметьте, это всё очень напоминает идею «трансвключения», когда между различными документами Сети создаётся «живая» связь, позволяющая условно говоря, включить содержание одного документа в другой документ. Гиперссылка, которая изначально предполагалась именно для трансвключения, реализует только лишь простой переход между документами…

                                                                                                  К чему приведёт такая организация дела? Например, к тому, что, во-первых, никогда не возникнет вопроса о первичных ключах и уникальных идентификаторах, во-вторых, легко единообразно применить любую форму отчётности, и, в-третьих, все бюджеты будут направлены на поддержание оперативной деятельности, а не на обслуживание оной. А чем издательская деятельность отличается от торговли? А образовательная? А проведение научных исследований? Везде можно найти аналоги складов, измерений, разрезов и всевозможных «счетов»! (Не хотите ли 1C в мировом масштабе?)))) А если суть происходящего укладывается в «прокрустово ложе» неких стандартных абстрактных объектов, операций и схем, то реализовывать нужно слой именно этой «абстракции». В качестве основного слоя представления для операционной системы. А уже все остальные задачи строить над ним.

                                                                                                  Да. Универсального решения нет. Я и не предлагаю. Но думать над этим полезно. Может быть, кто-нибудь додумается, как это всё сделать. Когда-нибудь.
                                                                                                    0
                                                                                                    Но что будет, если оформление всегда будет определяться конечным пользователем

                                                                                                    Вы считаете, что миллионы не связанных с IT людей согласны получать сообщения вконтакте или ссылки на видео на ютубе через json, и сами расставлять кнопки и плееры писать? Что конкретно вы предлагаете?


                                                                                                    можно ли разрабатывать программное обеспечение таким образом, чтобы

                                                                                                    Нет. И я вам об этом сразу сказал, причем кажется еще где-то в другой статье. И если вы вместо того, чтобы спрашивать, подумаете, как именно это сделать, то поймете почему.


                                                                                                    Представьте себе, что Вы — торговая фирма.

                                                                                                    Не-не-не. Я уже привел пример с комментариями. Почему вы уходите от ответа?


                                                                                                    а это значит, что сетевая инфраструктура должна реализовывать семантические сети в качестве одного из базовых протоколов.

                                                                                                    Как именно она должна это реализовывать? Ваши расcуждения опираются на какие-то волшебные штуки "оно само так работает".


                                                                                                    Например, к тому, что, во-первых, никогда не возникнет вопроса о первичных ключах и уникальных идентификаторах

                                                                                                    Какой именно вопрос и почему его не будет в вашей схеме? Что в таком случае будет указано в той "нагруженной связи"?


                                                                                                    Я и не предлагаю. Но думать над этим полезно.

                                                                                                    Вот когда придумаете, тогда и будете говорить, что существующие подходы неправильные. Критикуешь — предлагай.

                                                                                                      0
                                                                                                      И если вы вместо того, чтобы спрашивать, подумаете, как именно это сделать, то поймете почему.
                                                                                                      Да, было бы очень заманчиво додумать мысль до конца и либо, всё-таки, сделать что-то осмысленное и предъявить сие благородному сообществу, либо признать ошибочность собственных посылок и представлений. В любом случае, вариант беспроигрышный.
                                                                                                      Вот когда придумаете, тогда и будете говорить, что существующие подходы неправильные. Критикуешь — предлагай.
                                                                                                      Полностью подписываюсь под каждым Вашим словом. Засим, разрешите эту тему закрыть. (На перучёт.)))

                                                                                                      Большое спасибо за внимание и долготерпение.
                                                                                  +2

                                                                                  После фразы "Научить программировать можно любого — это легко." я понял что наступило время офигительных историй :-)

                                                                                    0
                                                                                    А это хороший вопрос: как следует обучать программированию? Что является самом сложным в программировании? Наверное, самое сложное — это понять, что даже в простых случаях надо действовать с полной выкладкой. Разве проблемы проектирования (больших систем) не проистекают от того, что разработчики дали себе «слабину» ещё на этапе малых дел?
                                                                                      0
                                                                                      Наверное, самое сложное — это понять, что даже в простых случаях надо действовать с полной выкладкой

                                                                                      Да, программист должен отдавать себя всего своему делу, а ещё программист должен любить всем сердцем, переводить бабушек через дорогу, порхать как бабочка и жалить как оса.
                                                                                      Разве проблемы проектирования (больших систем) не проистекают от того, что разработчики дали себе «слабину» ещё на этапе малых дел?

                                                                                      Нет. Проблемы проектирования возникают обычно от того, что они не жалили как оса.
                                                                                        0
                                                                                        Довольно странный ответ. «С полной выкладкой» означает, что он должен выполнить все предписанные некоей неписанной методологией этапы. То есть, даже в простом случае, делать всё, что полагается делать в сложном случае. Чтобы не кусать локти, когда поезд уже ушёл. К тому же, многие большие приложения начинались с маленьких, поэтому в больших приложениях остаются все огрехи «туманной юности».

                                                                                        P.S. Если Вам не понятна реплика, спрашивайте, а не «минусуйте»: виноват, надо выражаться яснее. Но… юмор оценил.
                                                                                          0
                                                                                          «С полной выкладкой» означает, что он должен выполнить все предписанные некоей неписанной методологией этапы

                                                                                          В том то и дело, что обычно нет. Если вы будете делать в простом случае всё, что полагается делать в сложном случае, вполне вероятно, что ваш продукт окажется просто неконкурентоспособным. Потому что пока вы будете делать красивую масштабируемую архитектуру, ваши конкуренты с написанным «по-быстренькому на коленке» продуктом будут делить рынок. А когда вы выйдете со своим запоздалым, но хорошим и отлаженным творением, у них уже будут деньги на развитие своих проектов, а у вас — нет. И они всегда будут на шаг впереди. Вы думаете, эти вот ребята
                                                                                          К тому же, многие большие приложения начинались с маленьких, поэтому в больших приложениях остаются все огрехи «туманной юности».

                                                                                          не знали, как писать софт «с полной выкладкой»? Пока вы продукт пишете, это здоровенная дыра в вашем кармане (или в кармане вашего инвестора), которая тянет и тянет ресурсы. Как только вы выходите на рынок, начинается обратный процесс. И для жизнеспособности проекта важнее, чтобы первый этап был намного короче. И обычно это намного важнее, чем заделы на будущее и правильное проектирование. Потому что если выход на рынок затянется, будущего может вообще не быть. А кривую архитектуру исправить в последующих версиях можно почти всегда. Равно как и много лет жить с костылями.
                                                                                            0
                                                                                            Вы всё правильно описываете. За исключением одной «малости»: за всё приходится платить, причём, далеко не сразу, и, часто совсем не тем, кто это всё затевал с самого начала. Быстрота выхода на рынок всегда оборачивается тем, что потом приходится тянуть тяжёлое наследие прошлого. Здесь получается крайне неприятная ситуация, когда по отдельности разные проекты показывают свою жизнеспособность (особенно на ранних этапах), а в целом для индустрии это оборачивается значительным торможением, когда сверх-короткий путь от идеи до реализации утверждает в индустрии подход, который вовсе не является наилучшим, просто, он был дороже всего продан.

                                                                                            (Однако, изначально, я смел виду гораздо более простой вариант «выкладки», когда мы формализуем все свои шаги, ничего не держим в голове, и делаем, даже, если делаем только для себя, делаем так, как если бы делали это для других.)

                                                                                            P.S. Могу привести один пример такого «технологического» решения, о котором мало говорят, если сказать, не говорят совсем, или, иногда, говорят слишком много. В своё время для кодировки символов стали использовать один байт. Это породило большую проблему кодировок. А теперь представьте, что, в своё время, разработчики специально задались бы вопросом: а как нам надо представлять символы? Можно ли признать решение в один байт хорошим решением? Нет, нельзя. А в четыре байта? А в восемь байтов? Вопрос, ведь, не в количестве байтов, хотя в стародавние времена экономический аспект был одним из важнейших, если не самый главный. Вопрос в архитектуре. Есть простые символы национальных алфавитов, есть диакритика. Есть управляющие символы с кодами (ASKII от 0 до 31), есть цифры, есть символы псевдографики. Всё это просто взяли и сложили в единый диапазон от 0 до 255. И что? Unicode решило эту проблему? Лишь, частично! А, теперь, представьте, каким был бы мир (от клавиатуры до компиляторов и офисных пакетов), если бы было найдено системное решение. Например, взяли бы и кодировали бы каждый символ тройками: <тип символа, номер символа, начертание символа> (надо бы это всё хорошенько продумать!). При этом, можно было бы организовать память таким образом, чтобы под каждый элемент тройки отводить своё количество байтов или битов. Это же можно было бы создать что-то вроде XML, только на самом низком уровне представления информации!
                                                                                              +1
                                                                                              Вы всё правильно описываете. За исключением одной «малости»: за всё приходится платить, причём, далеко не сразу, и, часто совсем не тем, кто это всё затевал с самого начала.

                                                                                              Верно. Но в большинстве случаев платить потом и больше, но когда проект раскручен — это намного проще, чем платить меньше сейчас, когда денег вообще нет.
                                                                                              А теперь представьте, что, в своё время, разработчики специально задались бы вопросом: а как нам надо представлять символы? Можно ли признать решение в один байт хорошим решением? Нет, нельзя.

                                                                                              Я могу не то, что представить, я могу уверенно утверждать, что они этим вопросом задавались. И знаете что? Оптимальным решением тогда было выбрано 7 бит. 128 возможных значений, это достаточно для всех знаков алфавита, цифр и ряда спецсимволов. Меньше современного байта, знаете ли. А потом, когда в моду вошли ЭВМ с восьмибитными байтами (на всякий случай отмечу, что байт — это не 8 бит, как часто говорят, а минимально адресуемый объем информации в ЭВМ, его размер зависит от архитектуры), это дало замечательную возможность локализовать их на разные языки.
                                                                                              А, теперь, представьте, каким был бы мир

                                                                                              Понимаете, Apple-II имела 4 килобайта ОЗУ в минимальной комплектации. Синклер — 16 килобайт. IBM PC — 64 килобайта, с возможностью расширения до 640К за кучу денег, PC XT — 256К, тоже с расширением до 640К. У программистов той эпохи стояла задача «как ещё ужать информацию», а не «а давайте раздуем текстовые константы в три раза, чтоб нашим детям через четверть века проще жилось». Поэтому решение с однобайтовым кодированием как раз отличный пример того, что всё должно быть своевременным.
                                                                                                0
                                                                                                Полностью подписываюсь под каждым Вашим словом. (Как, там, это называется? ПППКС?!?)))

                                                                                                Маленькое примечание. Когда появилась возможность использовать большие объёмы памяти, имело бы смысл делать новые компьютеры, и делать их на новых принципах. Но, поскольку, ничего этого сделано не было, всё, что мы имеем сегодня, суть наследие прошлого. Со всеми вытекающими.

                                                                                                Но системное решение заключается не в том, чтобы сразу дать под объект кучу битов или байтов («Бери пока дают!»), а в том, чтобы провести классификацию всех символов и найти для них оптимальное кодовое представление.
                                                                                                  0
                                                                                                  Точно уверены, что 50 лет назад смогли бы провести превентивную классификацию символа какашки? %)
                                                                                    +2

                                                                                    В принципе — математика — это же легко — все вытекает одно из другого, просто надо следовать логике и доказательство теорем само придет к вам в голову.
                                                                                    Юриспруденция — это легко, достаточно научиться пользоваться "Консультантом плюс" или Гарантом.
                                                                                    Фармацевтика — это легко, описание есть в любой упаковке с лекарством...


                                                                                    Список можно продолжать...

                                                                                      0
                                                                                      Это такой специальный тип статьи, чтобы срач в комментариях устроить? Замечательные аналогии просто на каждом шагу.

                                                                                      Много буков
                                                                                      Научить программировать можно любого — это легко

                                                                                      Агась. В ВУЗах-то люди, которые специально приходят научаться, и то не все осиливают. А тут эвона как — любого научить можно.

                                                                                      В школе нас обучили математике и письму, но это не сделало нас математиками и писателями.

                                                                                      Именно что сделало. Математиками и писателями. Нулевого уровня. Если дальше скилл не качать, то о лаврах Толстого мечтать глупо.

                                                                                      Большинство может легко научиться готовить...

                                                                                      Нанимают не повара, а кухню. И дело тут не в качестве, а в количестве — один человек физически не сможет «снабдить» 20+ гостей к означенному часу _свежими_ блюдами.

                                                                                      Разработчики ПО досконально изучают решаемые задачи, полностью понимают, как работают предложенные ими решения

                                                                                      В мире розовых коней — да. В реальном мире для сложного ПО с непростой предметной областью — разве что техлид имеет некоторое представление о картине в целом.

                                                                                      Прежде чем писать код, разработчик задастся следующими вопросами:

                                                                                      Как можно решить задачу, обойдясь без программирования?

                                                                                      Вряд ли я один такой особенный, но у меня одним из первых вопросов идет «а что забыли включить в ТЗ? Может можно решить еще какие-то задачи с помощью программирования?»

                                                                                      Когда разработчик пишет программу, он проверяет, чтобы она работала во множестве различных окружений, на машинах с разными ресурсами и в разных часовых поясах.

                                                                                      Опять же в мире розовых коней. В мире победившего капитализма разработчик в первую очередь проверяет, работает ли ПО на железе/парке заказчика.

                                                                                      Начинают с того, что называется сценарием по умолчанию

                                                                                      Тут мысль не совсем понятна. Я начинаю с поиска дыр еще на этапе составления/обсуждения ТЗ — «а что если на этом этапе юзер сделает Х, а не У (этот момент не обозначен в ТЗ, но возможен чисто теоретически)? Является ли такое развитие событий валидным сценарием?» и т.д.


                                                                                      Почтил традиции Хабра — поговорил с переводом.
                                                                                      П.С.: Пока не понял о чем статья. Завтра дочитаю.
                                                                                        0
                                                                                        Цитат Паскаля про письмо в оригинальной статье (ошибочно) приписано Марку Твену.
                                                                                        Я нахожу занятным тот факт, что переводчик потрудился проверить авторство.
                                                                                        Однако цитата, приписываемая Эйнштейну — скорее всего фольклор.

                                                                                        Дочитал статью, прочитал в оригинале. Много воды. Очень много воды. Суть Всей статьи может уместиться в одном абзаце:

                                                                                        Не надейтесь, что человек/команда без опыта создания большого ПО с нуля сделает качественное ПО. Даже если цена, названная этим человеком соблазнительно низка, скорее всего в итоге (даже если получите хоть как-то работающее ПО) вы потеряете сильно больше на этапе использования (плохие безопасность/поддержка/расширяемость/юзабилити).
                                                                                          0
                                                                                          ❶ Про статью. Вместо того чтобы использовать аналитический метод и сделать сравнительную таблицу по структуре и функциям «разработка» и «программирование», автор предпочёл формировать своё мнение на основе домыслов.

                                                                                          ❷ Про термины. Да, действительно, термины меняются со временем, например в результате глупости оратора/писателя или применения им демагогии.

                                                                                          ❸ Про комментарии. Информационно-ценные:
                                                                                          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
                                                                                            чем больше у программиста опыта, тем быстрее он создаст функциональное, точное, надежное решение, которое несложно будет поддерживать

                                                                                            Проблема определить, насколько правильный у программиста был опыт.
                                                                                              0
                                                                                              Понравилось. Ну, кроме, саморекламы.
                                                                                                +1
                                                                                                Хорошо промыли мозги, потом рекламка своей компашки опытный разработчиков.
                                                                                                  +1

                                                                                                  Всё хорошо написано! Правильно и складно!


                                                                                                  Но уже за столько лет существования нашей профессии… может хватит кормить комьюнити "песнями про профессионализм", "красивый код" и "грамотный подход".
                                                                                                  Мы разработчики и так понимаем как надо и как не надо. Это и так очевидно любому мало-мальски опытному человеку.
                                                                                                  Только что нам от ваших песен!!!
                                                                                                  Это шизофрения, это раздвоение личности!!!
                                                                                                  Это лицемерие!!!

                                                                                                  Все друг перед другом с умным видом рассуждают про "правильные подходы".
                                                                                                  Хабр, Медиум и еще овер-100500 конференций!


                                                                                                  … Но потом мы возвращаемся в реальный мир, на реальный рынок труда, к нашим работодателям. К этому дибильному "веку стартапов" и зайчиков-стартапщиков скачущих как ошалелые с дымом со всех мест. К этим даже большим компаниям — которые всё так же "пилят в угоду инвесторам" и "KPI-ям". Какие к чёрту пользователи, UX!!! О чём вы!!!


                                                                                                  В голове происходит — когнетивный диссонанс при попытке увязать "теорию красивого кода" и "практику экономического выживания".


                                                                                                  Свет истины уже пора бы нести не в "технические головы" а в "финансово-обеспечивающие" — тогда будет счастье и мир во всём мире.
                                                                                                  Только вот увы, любая "финансово-обеспечивающая" голова
                                                                                                  а) "заточена" жестко на извлечение прибыли
                                                                                                  б) видит 80% успеха далеко не в "качестве продукта"
                                                                                                  в) а иногда и наличие чётко-понятного продукта даже не обязательно))

                                                                                                    0
                                                                                                    Блез Паскаль

                                                                                                    Разве честно вносить такие правки при переводе?

                                                                                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                                    Самое читаемое