Каждый разработчик ПО умеет программировать, но не каждый программист может разрабатывать ПО
Большинство может легко научиться готовить, но когда нужно накормить большое число людей, мы нанимаем повара.
Возможно, кому-то больше нравится говорить не «разработчик», а инженер-программист, ведь инженер — это звучит гордо! Или нет? К счастью, эта статья не о терминах. Если мой термин вам не нравится — подставьте свой: «автор ПО», «мастер ПО»… и даже «творец приложений»!
Говоря «разработчик ПО», я имею в виду человека, для которого написание качественного ПО — профессия. Человека, который использует в своей работе научные подходы и статистику и считает свое занятие чем-то большим, чем просто зарабатывание денег.
Чтобы стать разработчиком, уметь программировать недостаточно.
Научить программировать можно любого — это легко. Писать простые программы, которые работают у конкретных людей на конкретных машинах, может почти кто угодно, но никто не гарантирует, что те же программы будут работать в других условиях.
Мне нравится такая аналогия: каждый может ради собственного развлечения петь в ду?ше, но вы же не ставите треки с записями этого пения на вечеринке — вы обращаетесь к произведениям профессиональных музыкантов.
Хотите еще аналогий? Пожалуйста:
- В школе нас обучили математике и письму, но это не сделало нас математиками и писателями.
- Большинство может легко научиться готовить, но когда нужно накормить большое число людей, мы нанимаем повара.
- Никто не зовет соседа — мастера на все руки построить дом с нуля.
Главная задача этого текста — донести, что создание простых программ серьезно отличается от разработки ПО.
Переведено в 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
Комментарии (91)
ProgrammerMicrosoft
01.11.2017 13:27Да я полностью согласен с тем что создание простых программ серьезно отличается от разработки ПО.
В любом случае, новичок, который решил стать опытным — программистом им в конце концов станет.
Но вот что меня немного смущает так это то что автор проявляет интерес к разным направлениям разработки и делает вывод на этом буквально следующий, а именно то что если обычный программист занимается в течение 10 лет разработкой всего подряд, то он может худо да бедно назвать себя опытным, а если другой разработчик занимается только мобильной разработкой, то он ещё не разработчик ПО так что ли? (1-3 года опыта)
Разработка программного обеспечения — занятие скорее относительно для всех кто действительно хочет и может этим заниматься.
Программист – это больше чем профессия это проявление истинного творца сравнимое с самим богом. Создание (творения) своей формы жизни правда пока не совершенной к примеру ИИ, умное ПО – (Симуляция жизни) или просто обычное приложение — всё это и есть результат программирования.
Как правило опыт может приобрестись быстро или медленно всё относительно того чем вы занимаетесь.
Допустим вы достаточно компетентны в Front-end но у вас нет опыта в Back-end и это нормально, так как это не делает из вас не до программиста!
Дело в том, что Программист учиться всю жизнь — но не программировать, а в покачивание своего Skill путём приобретения опыта в разработке!
SergeyGrigorev
01.11.2017 14:26Попробую несогласиться с вами. Я начинал писать с GUI приложений, потом приложения двух-звенные с БД, чисто sql отчеты размерами несколько тысяч строк кода, потом веб-приложения с множеством модулей, сейчас чисто backend-микросервисы. Кроме того, чисто для себя изучал программирование микроконтроллеров, писал на железе вообще без ОС. И весь этот опыт позволяет мне думать обо всех этапах работы кода, вплоть о том, как мои данные передаются и по сети и почему они могут вызвать проблему OutOfMemory на сервере на ровном месте казалось бы.
Недостаточно заниматься Front-End 10 лет и понимать при этом множество других аспектов. Это будет лишь «отличное понимаение как пишется Front-End». Автор скорее имел ввиду, что кто-то превосходно может разбираться в своей области, и это отлично, на самом деле, но недостаточно, чтобы предоставить возможность тому разработчику спроектировать новое приложение с нуля самостоятельно.
DrPass
02.11.2017 00:27Программист – это больше чем профессия это проявление истинного творца сравнимое с самим богом
Дело в том, что Программист учиться всю жизнь
Да куда там богам до программистов. Вы вон даже «бога» пишете с маленькой буквы, а «программиста» с большой.
По-моему, для некоторых программистов в жизни куда важнее проблема, чтобы у них морда от ощущения собственной офигенности не разорвалась.
OlegZH
02.11.2017 22:22А теперь, внимание, вопрос: что будет, если, даже, создание простых программ (программ, решающих отдельные простые задачи) будет полноценной разработкой? Я усматриваю, здесь, корень проблемы. Если этого разделения не было бы, и мы относились с одинаковым вниманием к задачам различной сложности, то избежали бы множества ловушек и делали бы ПО высочайшего качества.
Во-первых, в любую минуту может придти Некто, кто попросит даже в самом простом приложении прикрутить «вот эту фичу». Современные монструозные программы (ставшие целыми пакетами!) начинались с маленьких программок.
Во-вторых, Вы всегда будете думать о том, что было бы, если бы у Вас была готовая инфраструктура для создания различных приложений, наличие которой гарантировало бы Вам определённый (высокий) уровень качества программного кода. Сколько было за последние 30 лет предложено всевозможных «фреймвёрков», многие из которых уже давно исчезли из обихода? А если бы эта инфраструктура была бы ещё и частью ОС?
В-третьих, всегда возникает соблазн разбить большие приложения на маленькие. Зачем же мы создавали многофункциональное устройство, чтобы разрезать его на части? Может быть, было бы логичнее, иметь набор маленьких приложений, решающих маленькие задачи, и средство для сборки маленьких приложений для решения больших задач по требованию пользователя (в рамках ОС).
Только, где мы найдём таких разработчиков, которые смогут выявить эти самые элементарные кирпичики и составить из них полноцветные мозаики? На этот вопрос статья ответа не даёт.
timur560
01.11.2017 14:44Тема очень хороша и актуальна для текущего состояния отрасли IT, причем, если углубиться, обсасывается уже не один десяток лет. Шикарнейшая книга есть у Стива Макконнелла — «Профессиональная разработка программного обеспечения», где на протяжении всей книги сравнивается программист и инженер ПО. Инженерия говорит о зрелости отрасли, а эту зрелость обеспечивает очень и очень много факторов, и качество написания кода это хоть и важное, но только базовое качество которым должен обладать специалист-инженер.
О зрелости стоит говорить вплоть до уровня качества инженерного образования в стране и уровня сертификации специалистов. Много ли вы знаете программистов с сертификатами? А ведь многие сервисы ее предоставляют (Zend, AWS, MySQL, т.п.). Многие если и получают их, то лишь для собственного удовлетворения. Нам до этого еще расти.
Если вы инженер высокого уровня, то вы должны делать вклад не только в свой рабочий проект, но и в отрасль вцелом. Кто пишет книги по программированию, статьи, занимается разработкой новых технологий??? Многим из нас кажется, что этим должны заниматься Facebook и Google, но на самом деле этим должен заниматься каждый инженер высокого уровня, и это, собственно, один из показателей того, что вы инженер.
Выступаете ли вы на конференциях с новыми решениями актуальных проблем, ходите ли вы на них чтобы узнать о том, с чем сталкиваются другие компании и их инженеры? Это обсуждение можно продолжать бесконечно, суть в том, что инженер это больше чем качественный программист, и нужно учиться мыслить глобальнее. Не только строчками своего кода, но и на уровне отрасли инженерии ПО вцелом.
vasIvas
01.11.2017 15:01Лично мне кажется что тема надумана. Если я умею готовить и мне нужно приготовить на множество человек, то я не буду готовить только по двум причинам — 1) мне нужно заниматься чем-то ещё 2) я не умею готовить все блюда. Второе прямо говорит о том, что я не сформирован, как профессионал. И это не тот пример, когда школа не делает из на математиков, это когда первоклассник не в состоянии решить задачи выпускников. Тот разрыв, который демонстрируют на примере школы и математика, может выражаться лишь в различных профессиях, ведь создание ПО, это как аэропорт, где, естественно, все не лежит на плечах пилотов. ПО, это произведение которое играет оркестр, программирование, это написание произведения. И на примере этого. кажется что автор хочет сравнить оркестр с музыкантом.
mephistopheies
01.11.2017 15:15-1читать пост я конечно же не буду, но по картинке, очевидно, что аффтор не понимает о чем пишет
PapaBubaDiop
01.11.2017 15:26Про повара хороший пример.
Я предпочитаю обедать дома, а не в супер-профессиональном ресторане Урюпинска или Москвы.
Дома — вкуснее.
XopHeT
01.11.2017 17:18-2Рассказывал своим сотрудникам практически то же.
Покажу, пускай почитают, может Хабру поверят)
qpPeW
01.11.2017 17:18-3Недавно с друзьями рассуждали на тему «Программист, это творческая личность или нет?».
А как думаете Вы…?iBlackShadow
01.11.2017 18:49Думаю да, ибо как программист будет представлять себе прогу или что либо, так он ее и напишет, все равно что рисовать картину.
geher
01.11.2017 20:30А это зависит от того, что это за программист.
Программист прекрасно может быть совсем не творческим ремесленником, который по стандартным правилам превращает ТЗ в код.
И программист может быть творческой личностью, творящей программный продукт, создающей его архитектуру не "по образцу и подобию", а как нечто новое, придумывающей новые приемы программирования, новые языки программирования или даже новые парадигмы программирования (насчет последнего, кажется, что уже все придумано: ООП, ФП и т.п., но чем черт не шутит, может быть, еще что-то изобретут).
И все это будет совершенно правильно именоваться "программирование".
lxsmkv
01.11.2017 21:30На Хабре нельзя ставить под вопрос элитизм которым овеяна личность человека стоящего по ту сторону информационных технологий. (с) Я.
Но, иронию в сторону. Я для себя пришел к выводу, после того как перевел один текст с английского на русский, что программирование это работа переводчика. Сделав перевод, я подправил его с учетом рекомендаций читателей. И в скоре даже забыл про что был текст.кое-как нашел, вот
Crandel
02.11.2017 11:50+1Переводчик переводит с одного языка на другой. Программист — с человеческого языка на язык машины.
Что за бред? Какой такой язык машины? Все что может машина — менять 0 на 1 разными способами. Это больше похоже, что переводчик переводит текст на язык ракушек, которые реагируют на наличие света или тени. И то аналогия далека от реальности.
DrPass
02.11.2017 15:33Что за бред? Какой такой язык машины? Все что может машина — менять 0 на 1 разными способами
Да, а всё, что может человек — это поглощать органические вещества, расщеплять их, и синтезировать другие, ну и получать при этом энергию. Тоже, знаете ли, не слишком много.
Машина — это исполнитель. Она получает список команд из доступного ей набора и выполняет его. И скажите, вот например, солдат, который в общем случае умеет думать, но независимо от этого должен тупо выполнять команды командира подобно машине, он является аналогией компьютера? И если да, то переводчик, который переводит устав Красной Армии на немецкий язык, похож на программиста? ;)Crandel
02.11.2017 15:44Вас вообще не в ту степь занесло. Солдат не может тупо ничего выполнять, командир дает приказ, который солдат должен осмыслить и интерпретировать. К примеру "Займи позицию в доме напротив". Для машины нужно что-то типа 500 шагов на 32 градуса северо-восток, развернуться спиной к дому, присесть и тд. Переводчик переводит мысли других людей, вот и все. Ему не нужно придумывать алгоритмы, состояния системы, знать как устроена машина и еще кучу всего, что обьязан знать и делать программист. Аналогия совершенно не подходит.
lxsmkv
02.11.2017 16:37мне кажется все зацепились за слово переводчик, как профессию. Я же скорее имею ввиду переводчика как того, что переводит информацию из источника на язык получателя. И командир в таком случае, переводит информацию которую он получает о ситуации, в информацию (инструкции) для подчиненных, для выполнения задач.
В «защиту» своей «аналогии» процитирую еще книжку
«Решение задач на компьютерах» Москвитина А.А (с.320):
Чтобы понять природу ошибок ( а это нам необходимо при переходе от неформального описания задачи пользователя к формальной реализации ее в виде программы) при переводе рассмотрим модель [...] Ha на ней человек осуществляет перевод информации из представления А в представление B.
Может это более точное описание, той аналогии которую я имею ввиду.Crandel
02.11.2017 16:57мне кажется все зацепились за слово переводчик, как профессию
Как увидел, так и прореагировал
Романтики в этой профессии не больше чем в профессии переводчика. И творчества соответственно тоже. Переводчик может позволить себе удачный художественный оборот, чтобы выйти из положения когда прямой перевод невозможен. На этом пожалуй все «творчество» и заканчивается.
DrPass
02.11.2017 17:53Переводчик переводит мысли других людей, вот и все.
Не совсем так. «Человеческие» языки, если говорить о языках из разных групп, между собой отличаются очень сильно, не говоря уже о контексте, который понятен читателям И переводчик, если он не безмозглый подстрочник, это должен учитывать. Шутка про Пугачеву и Галкина в английском переводе должна превратиться в шутку про Хью и Кристал Хефнеров, а в арабском вообще исчезнуть или превратиться в шутку на другую тему.
Для машины нужно что-то типа 500 шагов на 32 градуса северо-восток, развернуться спиной к дому, присесть и тд.
Это лишь вопрос уровня абстракции. Современный программист ведь в подавляющем большинстве случаев работает с весьма высокоуровневыми библиотеками, и как раз отдает команды вида «займи позицию в доме напротив», понимая, что в библиотеке уже есть логика «зайти с заднего хода, закинуть гранату, потом под прикрывающим огнем заскочить и дать автоматную очередь». Да, её кто-то когда-то пошагово расписал, но это уже другая история.Crandel
02.11.2017 18:41Ему эти команды никто не расписывает. Тогда уже аналогия — из предложения "Хочу чтобы комментарии были на сайте" — написать роман с подробными шагами. Нету перевода, есть построение системы. "Хочу дом" — инженер его проектирует и строит, а не получил инструкции и перевел их в стены и двери.
bogolt
02.11.2017 14:47В таком случае учитель это человек который переводит язык взрослых на язык детей, а доктор — человек который переводит крики пациента в язык движений скальпеля.
lxsmkv
02.11.2017 15:13Про учителя в согласен, он переводит из ментальной модели взрослого в ментальную модель ребенка. Посредством например дидактической редукции. Доктор переводит из человеческого языка симптомов (тут болит) на формальный язык диагноза. И если заказчик (пациент) хочет это лечить врач предлагает известные ему методы избавления от симптомов и причин. (Что-то похожее на работу архитектора в айти). И передает работу хирургу, у кторого в конце концов на карточке написано что и где отрезать. Работа хирурга, практически не творческая. Но это все не значит что для этой работы не нужен талант. Талант нужен, чтобы свою функцию (ср. книги «Черновик», «Чистовик» у С. Лукьяненко) выполнять хорошо или лучше чем большинство других.
Вы уж простите за такую «механистическую» перспективу. Это всего лишь взгляд под другим углом.geher
03.11.2017 12:20В работе хирурга тоже есть место творчеству.
Что-нибудь отрезать можно разными способами.
Пришить тоже.
И эти способы нужно кому-то разрабатывать, а разработкой новых методов проведения операций занимаются обычно хирурги.
michael_vostrikov
02.11.2017 19:17Скорее не переводчик, а писатель или сценарист. «Напиши мне книжку про будущее и космические корабли на просторах Вселенной».
third112
02.11.2017 23:41Переводчик переводит с одного языка на другой. Программист — с человеческого языка на язык машины.
Забыли только, что программист иногда еще и алгоритм изобретает или адаптирует существующий под конкретную задачу. Что касается перевода с естественного языка на искусственный, то в общем случае такой перевод пока невозможен, кроме тривиальных случаев типа «два плюс два». Существующие искусственные языки даже теоретически не могут обеспечить многих соответствий с естественными. Но некоторым фантастам это не помешало выдумать, что в 22 веке все люди будут говорить на Алголе :))lxsmkv
03.11.2017 20:48вот, только что в комментариях к статье habrahabr.ru/post/341626 наткнулся:
github.com/web-standards-ru/dictionary/issues/178 — работа переводчика тоже может заставлять его адаптировать и придумывать новое. Это нисколько не тривиальная и не рутинная работа. Но это ремесло. (просто многие программисты относятся к плодам своей работы с преувеличенным трепетом, а на самом деле можно к этому просто относиться как к переводу, перевел, отредактировал, сдал, приняли, отлично, нет, отредактировал второй раз, сдал, забыл)
Однако и в дискуссии переводчиков (причем это однозначно технические переводчики, приобщенные к теме перевода) заметно напряжение, многополярность мнений, но в отличии от айтишников они никого за другое мнение не презирают, не оскорбляют, не минусуют, и не считают дураками, и в целом приветствуют эту дискуссиию.
В них нет этого ничем не оправданного элитизма, который я упоминал в изначальном комментарии и который я надух не переношу. А так все хорошие ребята.third112
04.11.2017 01:31Давайте не будем валить в одну кучу этические моменты и объективные оценки характера той или иной работы. Работа переводчика не всегда ремесло, это может быть научная работа. Пример: перевод В.П. Козырева книги Ф. Харари, Теория графов, М.: Едиториал УРСС, 2003. Переводчик — опытный математик и в его предисловии к переводу приводятся ссылки на его научные работы, опубликованные в солидных изданиях. Заслугой перевода является более четкая терминология по сравнению с оригиналом. Сам автор отмечает проблему терминологии (С.22 перевода). Кроме того добавлено много комментариев переводчика, облегчающих понимание. Интересно почему я занялся таким сравнением? — очень просто: когда пишу статью в русскоязычное издание цитирую перевод, а когда в англоязычное — оригинал.
Давайте не будем забывать, что программирование это не чисто инженерная область, но и область науки CS (computer sci., переводят как информатика). У этой науки большое пересечение с математикой. А основой всех программ являются алгоритмы. Как и в каждой науке в CS много рутины, но это не делает ее ремеслом. Хотя и в любой другой науке встречаются ремесленники — пусть это будет их личной проблемой.lxsmkv
04.11.2017 03:17+1Спасибо Вам за участие в обсуждении. Я эту дискуссию не ради базара начал, мне хочется понять, что делает этих людей особенными. Может мои наблюдения, на которых основаны, мои выводы однобоки. Потому что мне не с чем сравнить.
Мне, вобщем, не понятно, почему айтишники ставят себя всегда особняком. Ни одна инженерная профессия не порождает столько людей с завышеным самомнением, которые кичатся своими знаниями. Хотя в этой профессии нет ничего особенного. Ничего такого, что делало бы ее отличной от других профессий.
Вот когда программист начинает думать что его профессия — творческая, начинаются велосипеды и рвутся все дедлайны. Творческая работа скорее у программного архитектора.
А разработчик просто наполняет систему кодом. Как правило в сложных системах есть сложный фреймворк, но при этом каждый программист а пишет довольно простой код. Кладет свои кирпичи в раму. Но и тут находятся такие, которые кладут кирпичи поперек, поскольку ну раз нет спецификации, и никто не запрещает делать иначе, почему нет. Рама выложена кирпичами — чего тебе еще надо. Лишь бы сделать по-другому. Проявить свое творчество. Такие персонажи встречаются к сожалению. А может просто профессия засорена людьми без профильного образования.
В социальном плане эта профессиональная группа в основном состоит из крайностей. Или нерды-аутисты, или чуваки с синдромом Даннинга-Крюгера. Серединки маловато. У нас в команде из 20 человек «простых» ребят — меньше половины. К остальным, порой, не знаешь как подойти, чтобы не быть раздавленным их умственным превосходством. Не знаю с чем это связано, может и от возраста зависит.third112
04.11.2017 11:10И Вам спасибо за интересную постановку вопроса.
К остальным, порой, не знаешь как подойти, чтобы не быть раздавленным их умственным превосходством.
А здесь на Хабре разве Вас давят умственным превосходством? Посмотрел список Ваших недавних комментариев: показалось, что плюсов сильно больше, чем минусов.
У нас в команде из 20 человек
Довольно большая команда. Могут быть непростые взаимоотношения. Может дело в этом, а не в профессии?lxsmkv
04.11.2017 18:48Спасибо за ответ. Я тут еще раз подумал, и в купе с вашим замечанием, пришел к мысли, что вполне вероятно у меня просто искаженное восприятие. Просто у меня незаконченное айти образование, и скорее всего появился комплекс, из-за которого я слишком близко принимаю когда меня поправляют люди с большим опытом работы или знаниями. Или если я задаю какой-то вопрос, то мне кажется, что мне обьясняют категоричным надменным тоном, а на самом деле это просто мой комплекс приплетает подтекст которого нет. Надо будет понаблюдать за собой.
splav_asv
05.11.2017 10:23По описанию похоже на фундаментальную ошибку атрибуции. В части про других.
P.S. На мой взгляд у вас чуть упрощённое представление о задачах программиста, однако качественно всё так и есть. Я бы просто сравнивал скорее с инженерно строительной областью. хотелки -> ТЗ -> эскиз -> архитектурный проект -> планы систем -> инструкции для рабочих. хотелки -> ТЗ -> концепция -> архитектура -> задание на компонент -> программа. И тут вопрос, что из этого входит в работу программиста.
michael_vostrikov
04.11.2017 11:31Но и тут находятся такие, которые кладут кирпичи поперек, поскольку ну раз нет спецификации
К остальным, порой, не знаешь как подойти, чтобы не быть раздавленным их умственным превосходствомА как вы тогда определили, что поперек?) Можете примеры привести, может вы просто чего-то недопоняли?
lxsmkv
05.11.2017 09:00Хорошо, вот коротенький пример:
внутренне система различает четыре статуса соединения, но для сторонних программных клиентов мы выдаем только два. Есть числовые константы обозначающие для программного клиента статус соединения сервиса. Интерфейс поддерживает метод проверки валидности переданного значения. Так вот, чтобы обозначить для клиента что значение на валидно, разработчик решил передавать статус соединения -1. Его нет в константах. Обьяснил тем, что на данный момент у нас только один программный клиент — это мы сами, и там они договорились с разработчиком что -1 это невалидное значение. А если появятся другие клиенты то можно с ними договориться.
Т.е. мы максимально неверно используем собственный интерфейс. Не используем метод проверки валидности значения, а используем незадекларированную константу.
Вот что про это можно сказать. У меня только полярная лисица приходин на ум.michael_vostrikov
05.11.2017 10:03А вариант, что интерфейс спроектирован неправильно, вы не рассматриваете? Если обоим разработчикам удобнее использовать -1, значит надо поменять интерфейс.
Из описания не очень понятно, что куда передается, поэтому сложно сказать как будет правильно. Я представляю так.
В метод проверки валидности надо передавать результат вызова другого метода, например для установки соединения. Если там произошла ошибка, то логично возвращать -1. А собственно, какое значение предполагается возвращать (и проверять его валидность), если в константах нет значения обозначающего ошибку? К тому же вы предлагаете использовать 2 вызова вместо одного.lxsmkv
05.11.2017 11:19Данные о статусе передаются постоянно, и метод проверки валидности для того, чтобы отличать данные которые можно использовать, от тех которые нельзя. Возможно это сомнительный дизайн, но так сделано API передачи данных от системы к программным клиентам. Оно едино для всех системных компонент.
Я не знаю как правильно, я предлагаю придерживаться интерфейса. Я думаю, что если интерфейс будет в дальнейшем кем-то использоваться то, они будут работать с задекларированными константами. И получив -1 удивятся. Им придется звонить-писать нам, спрашивать в чем дело. Программист им обьяснит. Они договорятся. А можно ведь просто придерживаться интерфейса и не придется никому звонить. Вот и все. Так вот зачем эта самодеятельность. Чем она оправдана? Почему программист считает себя умнее архитектора? Вот что мне не понятно. Даже если он умнее архитектора, сделай как все делают, не переломишься ведь.
Вот возьмем работу какого нибудь мелкого гос-служащего, он же не ставит под вопрос недостатки процессов (лишние ненужные формуляры и т.п.), а просто выполняет ввереную ему работу. Но программист так не умеет.michael_vostrikov
05.11.2017 12:33То есть с сервера на клиент постоянно идет поток данных? Ок, пусть так, откуда берутся значения, которые там передаются? Почему там может быть что-то отличное от констант и почему нельзя сразу передавать -1, а нужно передавать какие-то другие невалидные значения и потом их проверять?
Я не знаю как правильно
А программисты знают.
Я думаю, что если интерфейс будет в дальнейшем кем-то использоваться то, они будут работать с задекларированными константами. И получив -1 удивятся.
Ну так задекларируйте -1 в константах. Это же ваша система, и сторонних клиентов пока нет.
Так вот зачем эта самодеятельность. Чем она оправдана? Почему программист считает себя умнее архитектора?
Потому что он с этим каждый день работает. И сам в некоторой степени архитектор. А почему умнее-то? Он же не переделывал систему, а просто передает значение, это системой разрешено, он пользуется ее возможностями.
Кроме того. Вот есть метод, принимает на вход значение, возвращает валидность. Почему вы решили, что нужно обязательно использовать именно его именно в этой ситуации? Его сделали, чтобы проверять, когда валидность неизвестна. А если пришло -1, то валидность известна, и ничего проверять не надо. Вы предлагаете делать лишнюю работу… для чего? Почему нельзя просто сделать как удобнее всем?
Но программист так не умеет.
Так он и не гос-служащий. Он инженер и решает задачи.
lxsmkv
05.11.2017 12:56клиент получает обьект с обновлением, и в нем содержится значение, и, используя метод проверки валидности, можно проверить валидность этого значения, т.е. можно этим значением пользоваться или нет. Например до полной калибровки системы значения невалидны и не должны отображаться.
Так вот значения не обязательно числовые, поэтому я так думаю архитектор делал булевый метод который для любого переданного значения дает валидность этого значения. С другой стороны аргументы разработчика тоже понятны. Что делать тестировщику?michael_vostrikov
05.11.2017 13:18Сказать «По документации должно быть 1 или 2, а у вас приходит -1, исправьте код или документацию» и отправить задачу разработчику.
Все равно непонятно, какое значение должен отправлять сервер, если ни одна из текущих констант не подходит? Почему нельзя использовать -1?lxsmkv
05.11.2017 14:27ну сервер посылает 0 сервис не доступен, 1 сервис доступен, (хотя внутренне различает четыре состояния, но это клиента не интересует) При инициализации он шлет наружу 0, и то что значение не валидно. т.е. обрабатывать его рано. А в интепретации разработчика поскольку нет других клиентов, он сделал 0, 1 и -1 причем первые две задекларированы а третье значение нет. Ну вот и получается что получается, нужно будет рано или поздно переделывать.
Вернувшись к аналогии с кирпичами, может это связано с тем, что как правило есть много поля для интерпретации в API, интерфейсах, документации. И соответственно там где нет четкого определения «правильно» разработчик включает мозги и делает свою интепретацию. Которая тоже не лишена смысла.michael_vostrikov
05.11.2017 15:00Если 0 это сервис недоступен, то что означает -1? Видимо это какая-то другая ситуация, не учтенная при проектировании.
lxsmkv
05.11.2017 17:01-1 это в понимании разработчика комбинация 0 и valid=false. Просто он это выражает одним не задекларированным значением, и фронтэнд работает с этим значением. И у этой «парочки» (наш фронтэндер + наш разработчик) на данный момент все хорошо. Но этот же поток данных может использоваться без предупреждения и другими клиентами, на то это и интерфейс. И тогда будет мягко говоря неловкая ситуация…
Вот и получается та ситуация которую я в частности критикую «я самый умный, я сделаю как я хочу и пофиг на всех остальных» и этому я не вижу никакого оправдания. Именно эта уверенность в своей правоте порой ошарашивает, нет бы хоть на минуту усомниться. Спросить архитектора или тех лида наконец.
Но не исключено, что это еще и возрастное, как правило разрабы за 30 уже не страдают такой бескомпромиссностью и уверенностью.
Или архитектор, может посмотреть на код и ляпнуть что-нибудь обидное в адрес разработчика. Зачем? Где коммуникационные навыки? Это тоже проявление ЧСВ. Можно ведь все тоже самое обьяснить нормально. Это поможет разработчику улучшить его навыки. А глупым оскорблением хорошего разработчика не воспитаешь. Вот и получается, что общаться между собой команда разработки практически не может, чтобы никогда никого не обижать. И вот о чем я говорю, что как мне кажется такое проявления ЧСВ — в особой мере присуще этой профессиональной группе.
То что по отношению к заказчику все профессионалы бывают чсв-шными от сантехника до врача — это мы знаем. Но между собой. Вот что удивляет больше всего.
lxsmkv
05.11.2017 11:25так вот, я тестировщик, мне что делать? Как тестировать такой интерфейс. По имплементации программиста или использовать только те константы которые задекларированы в интерфейсе. Т.е с точки зрения стороннего клиента который ни про какие -1 не знает.
OlegZH
05.11.2017 11:26А почему метод должен возвращать именно константу, обозначающую статус соединения? Кажется, что метод проверки валидности переданного значения должен возвращать булевское (логическое) значение TRUE/FALSE, а статус соединения — это должен быть отдельный объект. Логика здесь такая: если соединение установлено некорректно, то у него не может быть какого-либо собственного внутреннего статуса.
michael_vostrikov
04.11.2017 07:36+1но в отличии от айтишников они
Ну так и программист это не переводчик. Инженер, аналитик, писатель. А переводчик это вон компилятор.
И да, на Хабре тоже много напряженных многополярных дискуссий, где высказывают аргументы и которые только приветствуются.
DREMON
01.11.2017 18:49Научить программировать можно любого — это легко
Не соглашусь про легкость обучения программированию любого.
Недавно на хабре пролетала статья про это, но я нашел только несколько статей, про это. Краткое содержание этих статей: нет, программировать не легко, а повсеместные утверждения о том, что это легко, демотивируют начинающих программистов.
maxminimus
01.11.2017 19:12Лучшее, что произошло с языком JavaScript, — это TypeScript (и Flow). Статический анализ кода важнее, чем вам кажется. Если вы его не используете, вы, в сущности, становитесь уязвимы для возможных неизвестных проблем в будущем. Не пишите код без системы статического контроля типов. Если в выбранном языке нет статического контроля типов, нужно либо сменить язык, либо найти для него транскомпилятор: сегодня они уже достаточно умны, чтобы работать по комментариям в коде, и мне кажется, что для языков, не поддерживающих статический контроль типов, транскомпиляторы вскоре станут стандартным инструментом.
— это догмат.
Есть другая точка зрения:
Алан Кей сказал:
Я не против типов, но я не знаю ни одной системы с типами, которая бы не вызвала мучений, так что я по-прежнему за динамическую типизацию»
Пока мы не придумаем, как по-настоящему нужно разрабатывать софт, выходом может быть создание динамических систем с экстремально поздним связыванием во всех его проявлениях
Позднее связывание позволяет воплощать идеи на поздних стадиях разработки с экспоненциально меньшими усилиями чем традиционное раннее связывание как в C, С++, Java и прочих похожих языках
Если вы используете язык с ранним связыванием, как делает большинство людей, вместо языка с поздним связыванием, вы окажетесь взаперти у проделанной работы. Переформулировать что-то будет уже непросто
Тот кто ругает ЖаваСкрипт просто не понимает его прелесть, его смысл.
ЖаваСкрипт прекрасен, это вершина развития программирования, это как бы Лисп в шкуре Си.
Лисп и Си это самые крутые классические языки. Ну еще Пролог и Логлан можно выделить.
ЖаваСкрипт прекрасен тем что его можно освоить за один день: habrahabr.ru/post/332574
0xd34df00d
02.11.2017 03:43Если бы статические системы типов ограничивались лишь джавой или плюсами, то в таком мире и я бы жить не захотел. К счастью, есть более адекватные языки семейства ML.
hd_keeper
02.11.2017 12:41В JS нет макросов, так что это далеко не лисп.
maxminimus
03.11.2017 10:40Ты не уловил смысл — максимальный минимализм.
Чем проще язык тем лучше.
Минимальная сложность при максимальных возможностях.
Поэтому JS похож качеством дизайна на Лисп и Си.
Синтаксис языка JavaScript во многом напоминает синтаксис Си и Java, семантически же язык гораздо ближе к Self, Smalltalk или даже Лиспу
Я например использую только 50 элементов языка JS и 50 элементов языка CSS.
Эти языки в виде простого подмножества можно освоить за день.hd_keeper
03.11.2017 10:46От твоего комментария макросы в JS всё равно не появились. :P
maxminimus
05.11.2017 12:55Ты наверное слишком умный ))
Я не понимаю зачем это бывает нужно, и как я без этого программирую.
Druu
05.11.2017 14:01> Поэтому JS похож качеством дизайна на Лисп и Си.
Это в JS минимальная сложность? JS объективно сложнее по своей семантике, чем тот же си. И просто на порядок сложнее джавы.
lalaki
01.11.2017 20:41+1Коллеги, ИМХО перевод цитаты не совсем корректен:
"В компьютерных технологиях есть только две сложные задачи: недействительность кэша и придумывание названий"
— правильнее было бы "инвалидация кэша" (процесс + конкретный термин, не нуждающий в "русификации") и "придумывание имен" (более общая и частая задача — имена функций, классов и тп)
dkukushkin
01.11.2017 22:53В некоторых общественных столовых такую дрянь готовят, даже я приготовлю лучше. И при этом не стыдятся называть себя поварами…
Аналогично некоторые сервисы так дряно работают, все виснет, проводится в ручном режиме, нет нужного функционала. Но как то работает, люди туда приходят.
Так что не соглашусь. Если припрет и умеете готовить — сможете приготовить и котел жратвы на 100 чел. Может и не похвалят, но с голоду не помрут.
Tallefer
02.11.2017 03:07Каждый разработчик ПО умеет программировать
И сразу нет. :) Взять любой средний-большой игрострой (да и инди сойдет, если там больше 1 каски) — там есть дизайнеры, художники, моделлеры, музыканты. Это разработчики? Да. Умеют они погромировать? Нет. :)
third112
02.11.2017 03:36Главная задача этого текста — донести, что создание простых программ серьезно отличается от разработки ПО
Открыли Америку! Создание простых программ серьезно отличается от создания сложных программ! А создание сложных программ серьезно отличается от разработки ПО?
Разработчики ПО досконально изучают решаемые задачи, полностью понимают, как работают предложенные ими решения
Как быть с эвристическими алгоритмами? Они работают, но никто не может полностью понять, как они это делают… М.б. в разработке ПО такие алгоритмы не применяют? ;)
Разработчики ПО не считают своей работой просто написание программ — они рассуждают с точки зрения удовлетворения потребностей и решения задач. И это важно, потому что не для всякой задачи необходимо писать программу: в некоторых случаях достаточно использовать уже существующую программу
Человек, предложивший уже существующую программу — это разработчик ПО? Прихожу в магазин, прошу ОС или текстовый редактор, продавец выкладывает мне диски и коробки — он разработчик ПО! :)
У меня больше нет слов… нужна перезагрузка…geher
02.11.2017 08:46Человек, предложивший уже существующую программу — это разработчик ПО? Прихожу в магазин, прошу ОС или текстовый редактор, продавец выкладывает мне диски и коробки — он разработчик ПО! :)
Полагаю, что автор имел ввиду всего лишь повторное использование кода или программ в новом проекте. Но что получилось, то получилось.
fatronix
02.11.2017 10:35Статья — словоблудие и компенсирование непонятно чего. Давайте пойдем еще дальше и обсудим, чья музыка элитнее.
samizdam
02.11.2017 22:05Весьма вторичный материал.
Примерно те же мысли излагает Ф. Брукс в начале «Мифического человеко-месяца» приводя отличия «программы созданной программистами в гараже» от «системного программного продукта создаваемого промышленной командой».OlegZH
02.11.2017 22:36А, разве, со временем отличия не скрадываются? Не получается так, что промышленная команда (в погоне за гибкостью или, наоборот, за системностью) начинает походить на «гаражного программиста»? Когда какая-то промышленным образом разработанная система требует постоянной доработки, то, просто, мало кто воспринимает это негативно. Как можно выпустить «сырой» программный продукт? Это, конечно, сильный ход — сделать доработку частью жизненного цикла системы. Но, получается, что исправление ошибок проектирования выносится на этап эксплуатации. В реальных конструкторских разработках, хотя бы, используются натурные и полунатурные эксперименты. А в программировании таких экспериментов нет. Всё по живому.
И ещё один момент, который мало кто учитывает. Реальные приложения — это некие «конструкции», которые возведены над ОС и другими «конструкциями». Строго говоря, нельзя возвести хорошее здание без хорошего фундамента. Но программисты всегда пользуются тем, что есть. А Вы попробуйте поставить вопрос: как должна выглядеть ОС, чтобы мы писали эффективные приложения? Но тогда выяснится, что разработчики ОС просто выдали какое-то своё решение и получили за это свои деньги, а как им будут пользоваться, не подумали: продали — и ладно. А если подумали бы, то встроили бы в ОС свой родной язык программирования и среду разработки и… всё!samizdam
02.11.2017 22:53Если со временем профессионалы начинают в погоне за чем-либо нарушать промышленные стандарты, то это говорит о деградации процессов. Причины могут быть разные, в т.ч. и давление со стороны маркетинга или менеджмента в погоне за скорейшей прибылью, как вы выразились. Это печально. Но время всё расставит по своим местам.
А если подумали бы, то встроили бы в ОС свой родной язык программирования и среду разработки и… всё!
Напоминает MS + .NET + VS, как раз таки тот случай когда разработчики получили за это деньги.
Большинство альтернативных ОС, где разработчики просто выдают какое-то свое решение без родных языков и сред разработки, распространяется свободно.
Мне кажется во втором тезисе вы что-то перепутали)OlegZH
03.11.2017 14:27Мне кажется во втором тезисе вы что-то перепутали)
Возможно. На истину в последней инстанции не претендую. Просто, мысли вслух.
third112
02.11.2017 23:26В реальных конструкторских разработках, хотя бы, используются натурные и полунатурные эксперименты. А в программировании таких экспериментов нет.
Есть! — Вычислительные эксперименты, см. тут пример и ссылки на авторитетные источники.OlegZH
03.11.2017 14:31Спасибо за ссылку. Однако, я имел в виду вариант прототипирования целых предприятий, чтобы иметь возможность «прокрутить» систему на полигоне. (Или Вы предлагаете что-то вроде «13-го этажа», то есть за полную симуляцию окружающего мира?)
third112
04.11.2017 00:57Не важно целое предприятие или один станок с этого предприятия или один узел этого станка. Дело не в сложности. Эксперимент с деталью станка может быть сложнее. В приведенном примере дана игра — черный ящик и поставлена цель сделать программу-бота, взаимодействующего с этим ящиком в вычислительной среде, образующей полу-виртуальную реальность. Полу-виртуальную потому, что время, нпр., реальное. Если пойти путем мат.моделирования, то игра (прототип) заменяется программой-моделью, которая будет в некоторых важных нам случаях вести себя похоже. Остальные пути — работа непосредственно с прототипом, т.е. натурная. Могут быть использованы дополнительные вспомогательные средства контроля и созданы искусственные условия (аналог испытательного стенда) — тогда будет полу-натурная. В любом случае это экспериментальная работа в полном смысле этого слова. Один из измерительных приборов — секундомер (может быть внешний, а может таймер ОС).
michael_vostrikov
03.11.2017 07:53Но, получается, что исправление ошибок проектирования выносится на этап эксплуатации.
Ошибка это когда есть несоответствие между тем "что есть" и тем "как надо". Вы исходите из неправильного предположения, что "как надо" никогда не меняется, и в процессе эксплуатации оно такое же как во время проектирования. Поэтому нет, не получается.
OlegZH
03.11.2017 14:35Вот это-то меня и беспокоит: когда меняется представление о том, «как надо». Если бы для каждого вида деятельности существовал некий стандарт, и все неукоснительно соблюдали бы выбранный стандарт, то разработчикам не надо было бы общаться с клиентами, а, просто, брать готовый стандарт и реализовывать именно его. Но, это так, мои мысли вслух, заметки, так сказать, на полях.
michael_vostrikov
03.11.2017 14:44Если реальность расходится с вашими желаниями, это все равно не «ошибки проектирования».
michael_vostrikov
03.11.2017 14:51Если бы для каждого вида деятельности существовал некий стандарт
Опишите стандарт на веб-сайт.
OlegZH
05.11.2017 11:32Возражаете, возражаете, а тут… Зачем кому-то мог бы понадобиться стандарт на сайт? Речь идёт о деятельности, которая не имеет никакого отношения к сайту. Если такой стандарт (на деятельность) есть, то что мешает запрограммировать его в виде компонента операционной системы? И зачем тогда нужен будет сайт? Нужен будет только поставщик данных и получатель данных.
michael_vostrikov
05.11.2017 12:52Вы говорите, что в процессе жизненного цикла системы не должно быть доработок, что это ошибки проектирования, что нужен стандарт, по которому эту систему будут делать. И говорите, что если сделать по стандарту, то потом доработки будут не нужны.
Веб-сайт это система. В процессе его жизненного цикла в него вносятся доработки, потому что требования поменялись. Либо опишите стандарт, который учтет все возможные доработки, либо признайте, что доработки не являются ошибками проектирования.
И зачем тогда нужен будет сайт? Нужен будет только поставщик данных и получатель данных.
Веб-сайт это был пример системы. С целью чтобы вы задумались о том, почему невозможно то, что вы предлагаете. Ок, приведите стандарт на компонент операционной системы.
Ладно, возьмем пример попроще. Опишите стандарт на компонент комментария, реализовав который, можно будет не делать дальшейшие доработки во время жизненного цикла системы, где используются комментарии.
alz72
02.11.2017 22:22+2После фразы "Научить программировать можно любого — это легко." я понял что наступило время офигительных историй :-)
OlegZH
05.11.2017 11:51-1А это хороший вопрос: как следует обучать программированию? Что является самом сложным в программировании? Наверное, самое сложное — это понять, что даже в простых случаях надо действовать с полной выкладкой. Разве проблемы проектирования (больших систем) не проистекают от того, что разработчики дали себе «слабину» ещё на этапе малых дел?
DrPass
05.11.2017 15:44Наверное, самое сложное — это понять, что даже в простых случаях надо действовать с полной выкладкой
Да, программист должен отдавать себя всего своему делу, а ещё программист должен любить всем сердцем, переводить бабушек через дорогу, порхать как бабочка и жалить как оса.
Разве проблемы проектирования (больших систем) не проистекают от того, что разработчики дали себе «слабину» ещё на этапе малых дел?
Нет. Проблемы проектирования возникают обычно от того, что они не жалили как оса.
alz72
02.11.2017 22:29+1В принципе — математика — это же легко — все вытекает одно из другого, просто надо следовать логике и доказательство теорем само придет к вам в голову.
Юриспруденция — это легко, достаточно научиться пользоваться "Консультантом плюс" или Гарантом.
Фармацевтика — это легко, описание есть в любой упаковке с лекарством...
Список можно продолжать...
haldagan
03.11.2017 00:06Это такой специальный тип статьи, чтобы срач в комментариях устроить? Замечательные аналогии просто на каждом шагу.
Много буковНаучить программировать можно любого — это легко
Агась. В ВУЗах-то люди, которые специально приходят научаться, и то не все осиливают. А тут эвона как — любого научить можно.
В школе нас обучили математике и письму, но это не сделало нас математиками и писателями.
Именно что сделало. Математиками и писателями. Нулевого уровня. Если дальше скилл не качать, то о лаврах Толстого мечтать глупо.
Большинство может легко научиться готовить...
Нанимают не повара, а кухню. И дело тут не в качестве, а в количестве — один человек физически не сможет «снабдить» 20+ гостей к означенному часу _свежими_ блюдами.
Разработчики ПО досконально изучают решаемые задачи, полностью понимают, как работают предложенные ими решения
В мире розовых коней — да. В реальном мире для сложного ПО с непростой предметной областью — разве что техлид имеет некоторое представление о картине в целом.
Прежде чем писать код, разработчик задастся следующими вопросами:
…
Как можно решить задачу, обойдясь без программирования?
Вряд ли я один такой особенный, но у меня одним из первых вопросов идет «а что забыли включить в ТЗ? Может можно решить еще какие-то задачи с помощью программирования?»
Когда разработчик пишет программу, он проверяет, чтобы она работала во множестве различных окружений, на машинах с разными ресурсами и в разных часовых поясах.
Опять же в мире розовых коней. В мире победившего капитализма разработчик в первую очередь проверяет, работает ли ПО на железе/парке заказчика.
Начинают с того, что называется сценарием по умолчанию
Тут мысль не совсем понятна. Я начинаю с поиска дыр еще на этапе составления/обсуждения ТЗ — «а что если на этом этапе юзер сделает Х, а не У (этот момент не обозначен в ТЗ, но возможен чисто теоретически)? Является ли такое развитие событий валидным сценарием?» и т.д.haldagan
03.11.2017 09:23Цитат Паскаля про письмо в оригинальной статье (ошибочно) приписано Марку Твену.
Я нахожу занятным тот факт, что переводчик потрудился проверить авторство.
Однако цитата, приписываемая Эйнштейну — скорее всего фольклор.
Дочитал статью, прочитал в оригинале. Много воды. Очень много воды. Суть Всей статьи может уместиться в одном абзаце:
Не надейтесь, что человек/команда без опыта создания большого ПО с нуля сделает качественное ПО. Даже если цена, названная этим человеком соблазнительно низка, скорее всего в итоге (даже если получите хоть как-то работающее ПО) вы потеряете сильно больше на этапе использования (плохие безопасность/поддержка/расширяемость/юзабилити).
Antislovoblud
03.11.2017 12:38-1? Про статью. Вместо того чтобы использовать аналитический метод и сделать сравнительную таблицу по структуре и функциям «разработка» и «программирование», автор предпочёл формировать своё мнение на основе домыслов.
? Про термины. Да, действительно, термины меняются со временем, например в результате глупости оратора/писателя или применения им демагогии.
? Про комментарии. Информационно-ценные:
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, словоблудие.
reinvent
03.11.2017 18:11чем больше у программиста опыта, тем быстрее он создаст функциональное, точное, надежное решение, которое несложно будет поддерживать
Проблема определить, насколько правильный у программиста был опыт.
geher
Да, термины меняются со временем.
Меня учили, что программирование состоит из следующих этапов:
Тестирование и реализация обратной саязи с пользователем к программированию уже не относится, но могут быть реализованы частично или полностью посредством программирования.
А разработка ПО включает помимо программирования еще тестирование, организацию обратной связи, планирование рабочего времени, управление персоналом (даже если весь персонал — один человек).
То же, что названо программированием, у нас называлось кодированием.
hexploy
Сначала дискредитировали кодеров, теперь общество желает крови несчастных программистов. Получается что программист — это плохой разработчик, а кодер — плохой программист.
И судя по всему, если вы всего лишь разработчик, то вам рано расслабляться…
OlegZH
Зачем плодить сущности сверх необходимости?
Есть номинальные понятия, связанные с тем, какую функцию выполняет человек в определённый момент времени. Есть определённые позиции или вакансии. Вопрос в том, что является результатом своего труда.
Если результатом труда является программа, то речь идёт о программировании. В конце-концов, программа (в самом широком смысле) — это упорядоченная (в том числе, и во времени) совокупность предписаний, что и когда делать, позволяющая перевести систему из одного положения (полное отсутствие автоматизации) в другое (полная автоматизация всех бизнес-процессов).
Роли, здесь, не играют… никакой роли.
Хорошие программисты могут, конечно, между собою называть плохих программистов «кодерами», но особого смысла в этом нет. Другое дело, что в программировании для большинства программистов можно найти более продвинутых программистов, умеющих что-то ещё. В итоге, хороший программист — это тот прграммист, который знает, что ему всегда надо узнать что-то ещё. В этом смысле, все классификации заведомо слабы, поскольку никак не учитывают живую природу человека, который, если он не бездельник, завтра будет, уж точно не таким, как вчера.
RomeoGolf
Это уж точно.
Не путайте разработку ПО и программирование,
Не путайте постройку домов и строительство,
Не путайте написание книг и писательство…
OlegZH
Да. Всё это должно быть так. Но, к сожалению, так происходит не всегда. Часто один и тот же человек вынужден совмещать различные функции.
Но, лучше не «спотыкаться о термины», а говорить о том, что можно и нужно писать хорошие программы, а можно (хотя и это неприемлемо) писать плохие. Можно расписать красивую структуру требований и подзадач, но ошибиться в анализе и промахнуться в реализации. Недаром, говориться «Семь раз отмерь...». Кто же просит программиста стразу резать? Никто. Только он сам.