Программирование — отстой! Или что-то вроде того

http://thedailywtf.com/Articles/
  • Перевод
Предлагаю вниманию читателей перевод статьи "Programming Sucks! Or At Least, It Ought To", опубликованной в «The Daily WTF». Публикация рассказывает о том, как избыток профессионализма на практике мешает эффективности и предназначена скорее для опытных разработчиков, нежели для новичков.

Программирование — это не забава. Это нудное и скучное занятие, и, уж конечно, никакой не подвиг. Чего бы вы там с ним не делали, программирование совершенно точно не будет «секси».

Я знаю, что вы думаете. Всех, кто так говорит — и уж тем более пишет такое в блогах — нужно немедленно лишить их программерской лицензии, отобрать у них клавиатуры и навечно посадить за микроЭВМ с CP/M, 8"-ми дискетами и модемом на 1200 бод.

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

Почему мы пишем код?


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

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

Хотя порой грань между «скучным» и «секси» софтом может размываться, «секси-программы» представляют собой то, чем мы с вами пользуемся регулярно, каждый божий день: SVN, Google Maps, Visual Studio, Firefox и т.п. По сути, нам как программерам редко приходится пользоваться каким-то нудным ПО.

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

Основы унылого ПО


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

Формальный процесс создания этих информационных систем впервые появился ещё в 60-х годах, а с 70-х вообще практически не поменялся ( Современный Структурный Анализ на диво всё ещё современен). В сущности, вы анализируете проблему, составляете карту потоков данных, структурируете эти потоки, создаёте базу и пишете программы, которые являются интерфейсом для работы с БД.

Мы перешли от «тонких клиентов» в «зеленоглазых» терминалах к «толстым клиентам» в виде приложений для ПК. Затем мы переметнулись к «тонким клиентам» на вебе, а с платформами наподобие Windows Presentation Foundation и глазом моргнуть не успеем, как снова окажемся рядом с «толстыми клиентами». Как бы там ни было, наши системы продолжают делать одно и то же: запись/чтение данных.

Разработка информационных систем особо не поменялась. Не важно, используете ли вы Visual Basic 3.0 или xHTML, принципы остались практически теми же: база данных должна быть представлена взору пользователя в максимально приятном и дружественном свете. Код, который для этого необходим (и всегда был необходимым), довольно уныл:
txtFirstName.DisplayWidth = 30;
txtFirstName.MaxCharLength = 50;
SetTextBoxValidator(txtFirstName, Validations.LettersOnly);
txtFirstName.Enabled = securityContext.CanEdit;
txtFirstName.Value = customerRecord.FirstName;

Эти пять строчек кода, просто устанавливают некоторые свойства UI. Повторите это для каждого поля, каждой сущности, а затем умножьте ещё на 1,5, просто потому, что некоторые поля должны быть доступны из двух разных мест. А теперь добавьте весь код, необходимый для валидации и сохранения данных, полученных из UI. Если математика меня не подводит, в результате мы получаем туеву хучу унылого, скучного кода.

Дилемма разработчика


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

Здесь-то и кроется загвоздка. Как выразился Майкл А. Джексон в своих «Принципах проектирования программ» 1975 года, «Программисты… часто находят спасение в их, в общем-то, понятном, но на деле губительном стремлении к усложнениям и ухищрениям в своей работе. Отстранённые от создания чего-либо большего, чем просто программа, они отвечают тем, что делают эту программу до такой степени замысловатой, чтобы она была достойным вызовом для их профессиональных навыков».

Это наблюдение 35-летней давности изо дня в день находит свои подтверждения здесь, на «The Daily WTF». Самый изощрённый код и истории, опубликованные тут, порождены тягой разработчика к достижению мастерства. Эти стремления никоим образом не являются неким заблуждением или результатом злого умысла, они инстинктивны.

Когда я писал о soft-кодировании, я привёл фрагмент, на который должно быть похоже большинство написанного кода, то есть самого специфичного кода, реализующего самые особенные бизнес-требования. Он довольно скучный:
private void attachSupplementalDocuments()
{
if (stateCode == "AZ" || stateCode == "TX") {
//SR008-04X/I are always required in these states
attachDocument("SR008-04X");
attachDocument("SR008-04XI");
}

if (ledgerAmnt >= 500000) {
//Ledger of 500K or more requires AUTHLDG-1A
attachDocument("AUTHLDG-1A");
}

if (coInsuredCount >= 5 && orgStatusCode != "CORP") {
//Non-CORP orgs with 5 or more co-ins require AUTHCNS-1A
attachDocument("AUTHCNS-1A");
}
}


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

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

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

Конечно, те из нас, кто живёт в реальном мире, отдают себе отчёт в том, что подобные «экспертные системы» существуют только в стране фей, единорогов и безпотерьного сжатия случайных данных. Но есть другая реальность, которую многим из нас следует принять: разработка прикладных программ — отстой, и никакое количество XML-я или паттернов проектирования этого не изменит.

Просто примите это


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

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

Я уверен, что многие адвокаты с горящими глазами уцепятся за первый же захватывающий судебный процесс, но также быстро отступят, если такое решение будет лучшим выходом для клиента. Архитекторы мечтают заполучить возможность а-ля Fallingwater, но если проект требует постройки большого склада с разгрузочными доками — это будет единственным, что они нанесут на чертежи. И если нашему работодателю требуется софт для управления платёжными ваучерами, то он должен получить именно его, а не «систему, основанную на плагинах с масштабируемыми и распознаваемыми в реал-тайме шаблонами UI» или в необходимости чего там ещё мы сами себя убедим.

Переосмысление разработки ПО


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

Всё, начиная от платформы ("А давайте попробуем Руби!"), включая архитектуру ("да тут не может быть только два уровня") и заканчивая техниками, которые непосредственно используются в коде ("нам нужен аспектно-ориентированный фреймворк!") могут быть — а часто так и есть — продиктованы больше желанием изучить новую технологию, нежели реальными нуждами бизнеса. Выберите неверную платформу или изобретите ошибочную технику, и проект неизбежно обречён.

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

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

2. Служите интересам бизнеса.
Каждый ремесленник хочет использовать самые последние, великолепные и мощные инструменты, но они редко необходимы для работы. Подобно этому практически никогда невозможно мгновенно обновить платформы/библиотеки/языки. Тот код 10-летней давности, написанный на «классическом ASP», не устарел — его просто не так прикольно сопровождать.

3. Учитесь вне работы.
Саморазвитие — это главный принцип любой профессии, но заниматься этим следует «вне работы», то есть не во время разработки информационных систем. Вместо этого учитесь, создавая приложения для себя, вашей команды, или даже для каких-то open source проектов. Пояснение: «Вне работы» не означает, что вы вообще не должны учиться в процессе работы. Обучение важно, но не занимайтесь им в процессе разработки информационных систем для заказчика. Приберегите это для ваших собственных или внутрикомандных проектов.

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

5. От скуки не уйти.
Никакие O/R-мапперы или генераторы кода не смогут избавить вас от факта, что записи, поля, валидаторы и т.п. должны быть прописаны вручную, по крайней мере, в двух местах (фронт-энд и бэк-энд). И UI, генерируемая из базы — это также плохо, как база, генерируемая из UI.

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

… и, если ничто не помогает,…

7. Найдите себе другую работу.
Возможно, вы достигли своего максимума на этой работе. Или может вас просто тошнит от такого типа программирования. Как бы там ни было, существует целая масса программерских возможностей, которые не включают в себя скуку и информационные системы. Конечно, конкуренция будет намного выше, поскольку шедевры наподобие «The Brilliant Paula's bean» рождаются только в недрах IT-корпораций.

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

Подробнее
Реклама
Комментарии 113
  • +17
    Даже не поспоришь…
    • 0
      коммент на уравне спамабота
      • НЛО прилетело и опубликовало эту надпись здесь
    • +3
      >>Настоящие рок-звёзды сдают проекты до намеченного срока и дешевле отведённого бюджета, и это именно то, в чём нуждается бизнес

      Пошел ставить новую фразу на screensaver :) просто и очень сильно сказано
      • +5
        никогда не получалось сдать раньше сроков :(
        соответственно, второй пункт вступал в силу автоматически
        • +12
          … И если нашему работодателю требуется софт для управления платёжными ваучерами, то он должен получить именно его, а не «систему, основанную на плагинах с масштабируемыми и распознаваемыми в реал-тайме шаблонами UI» или в необходимости чего там ещё мы сами себя убедим.

          Чуть не расплакался. Помниццо принимал участие в проекте одном, который в итоге держа нагрузку в сотни раз большую чем расчетная, а также очень масштабируемом, но свет он увидел уже после того как пришлось попрощаться с работодателем (сам ушел, по собственному желанию)
          • НЛО прилетело и опубликовало эту надпись здесь
            • 0
              Умный босс ;)
              Като занимался организацией кастомной раскраски машин, и первой мыслью было показывать заказчику все этапы работы чтобы не волновался… Перепуганое лицо заказчицы которой показали ее машину ободраном виде с первыми набросками картины убедило меня что это была крайне плохая идея ;)
          • +2
            По-моему, нужно просто активно использовать свои наработки, а ещё рефакторить, рефакторить и рефакторить. Тогда даже от одного вида гармонично сложенного кода будет тепло на душе.
            • +3
              Про рефакторинг, случай из жизни.

              Дано:
              • команда разработчиков некого электронного устройства;
              • устройство, очень энергонасыщенное (в объеме 3 пачек сигарет почти 1 кВт.);
              • увлекающийся усовершенствованиями генеральный директор.

              и как в анекдоте — Петрович, смари! Новые индуктивности от Epcos, с нашими «самомотайками» не сравнить! 1 % КПД! Заказываем? итд. итп.

              В итоге.
              20 итераций промышленного образца и контора благополучно профукала бюджеты. )
              • +5
                Это из другой оперы. Рефакторинг ПО никак не нарушает работу системы (если нарушает — это не рефакторинг), естественно, он должен проводиться в окружении тестов. Тесты выполняются почти мгновенно (если запускать их избирательно), каждый день проводятся глобальные дымовые тесты… Короче, чего я вам теорию пересказываю, её можно где угодно вычитать. И там же, скорее всего, будет приведены практические показатели — чёткий и ясный код быстрее писать, легче сопровождать и он быстрее работает (зачастую), следовательно если рефакторинг позволяет снизить затраты, то выход за рамки бюджета = ошибка в требованиях. В любом случае, рефакторинг должен быть не время от времени (ой, ё-маё, что это он понаписал?), а постоянным.

                Плавно мысль перетекает в бравое TDD. В пику традиционному «программированию по требованиям» TDD даёт больше fun'а. Это не значит, что традиционное программирование скучное и нудное занятие. Я просто думаю, что автор статьи не на своём месте находится (возможно, нет перспектив роста или ещё что), короче ему просто нужно сменить обстановку :)

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

                  А вот участие в OpenSource проектах зачастую полезно. Это ведь общение с единомышленниками, решение интересных задач, может быть даже в каком-то роде социалистическое соревнование (кто лучше напишет код).

                  А может автору просто пора в отпуск на Гаваи:))
                • +2
                  Совершенно верно камрад! Грамотно проектировать, быстро «кодить» на одной ноге ;-) и рефакторить, рефакторить, рефакторить.
                  Недавно в одном разделе системы заказчик попросил срочно поменять представление данных и источник данных. Я сначала подумал о двухнедельном сроке выполнении этой задачи, но в итоге был затрачен только ОДИН «вечер» (изменение запроса, добавление пары строчек в модулях, пара строк в интерфейсе, плюс пара новых картинка и строчка в конфигурационном файле). Тогда я сказал — это КЛЕВО, это ЧУДО, это ГАРМОНИКА! А на следующее утро вместо графика работ показывали тестовую версию реализованных пожеланий заказчика.
                  • +3
                    Зря. Теперь от вас будут ожидать такой же оперативности и в реально сложных вещах; и вы в прицнипе не сможете объяснить неспециалисту, почему оно требует так много времени.
                • +5
                  Программирование уверенно идет (или уже пришло?) к конвейеру Генри Форда. Согласен с основными мыслями автора, но, думаю, стоит дополнить, что писать «потрясающе-элегантный, умопомрачительно-инновационный код» нужно хотя бы для себя. Иначе в итоге единственным удовлетворением от работы будут зеленые бумажки. А это хоть и крайне нужная вещь, но явно недостаточная для счастливой жизни вообще и развития себя как специалиста в частности.
                  • +2
                    То, что идет/пришло к конвейерному производству, продолжает называться «программированием» лишь по нелепой традиции.
                  • 0
                    7. Найдите себе другую работу.

                    Все верно.
                    В процессе кодинга в итоге от него отказался — в команде программистов должен быть кто-то, кому фиолетово (хотя бы внешне) что творится с обратной стороны UI. В итоге, действительно, пока сам программировал, то валил все сроки ради очередной красивости — ладно внешней, а то внутренней. А когда наконец то надавал себе по рукам и перестал писать строки кода (немного принципиальных концептов может быть, каюсь, грешен) то разница между ожидаемым и достигнутым не превышает 10%.
                    • +8
                      Как говорит мой начальник, есть три основные принципа при разработке ПО — KISS, 80/20 и лучшее — враг хорошего. Тут я с ним согласен.
                    • +4
                      Очень хороший и приятно читаемый перевод, в отличие от многих других. Респект.
                    • +5
                      не показывать эту статью унылым менеджерам и унылым руководителям!!!
                      не дадим себя превратить в винтики, и серую массу мы не китайцы и японцы!

                      :)

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

                      но и спасибо автору и переводчику — нахватался замечательных фраз :)
                      • 0
                        некая ирония состоит в том, что переводчик как раз менеджер :) правда, вроде бы не унылый :))
                      • 0
                        Отчасти верно… Очень верно.

                        По большому счету, клиент меряет состояние продукта двумя показателями: работает — не работает.

                        А что там внутри, ему не важно. Другой вопрос, а вдруг в перспективе будет расширение? Только вот на практике, пока не одному проекту, выполненному с возможностью гибкого масштабирования, таковое в глобальном масштабе не понадобилось…

                        Грусто, все это, товарищи. Грустно.
                        • НЛО прилетело и опубликовало эту надпись здесь
                          • 0
                            Часто клиент не очень-то понимает, что значит «работает», у него есть какие-то свои представления о том, как это должно выглядеть, у программистов свои представления, а ещё у менеджеров представления. В итоге получается НОД от всех ожиданий.
                          • НЛО прилетело и опубликовало эту надпись здесь
                            • 0
                              Последний абзац подтверждается жизнью.
                              • +2
                                Вы просто неимоверно чертовски правы в целом! Последний абзац отличное резюме всего сказанного.
                                А слова о том, что «возможно вы достигли максимума на этой работе»… в свое время я его не достиг, но четко увидел, где он находится, потому и перестал программировать сам.

                                А еще часть общей идеи, которая, к сожалению, не каждому понятна долгое время — это то, что программирование — это, скорее, больше рутина, нежели «искусство и постоянно что-то новое». Многие же хотят видеть себя «художниками» в своей профессии, и отсюда множество несогласных, сорванных проектов и стереотип о том, что программеры ничего и никогда не смыслят (и не могут смыслить) в бизнесе, а также «обиженные» программеры, считающие, что «да эти руководители, итить их в качельку, нихрена не понимают в нашей работе и технологиях». А я думаю, что по причинам, озвученным в топике, они просто никак «не договорятся».
                                • +3
                                  Самый важный из семи пунктов — первый: изучайте бизнес. В большинстве случаев заказчик плохо представляет, что ему надо, и дословное соблюдение его требований ведет к унылому малоосмысленному набору бизнес-правил и унылому коду. Обычно заказчика можно убедить, что ему нужно нечто более элегантное.
                                  • 0
                                    И то что к сожалению не всем программистам дано. Обычно идет изготовление «по техзаданию», что заканчивается разочарованием с обоих сторон.
                                    • 0
                                      Поэтому нужно искать айтишников, которые умеют понимать, разбираться и чётко формулировать.
                                    • 0
                                      Для начала вам придётся его убедить в необходимости заплатить вам за изучение его бизнеса. Обычно на этом пункте все заканчивается :)
                                      • 0
                                        Заказчик платит за продукт — и ему, в общем-то, пофиг, насколько ты знаешь его бизнес. Но при этом для создания адекватного продукта бизнес знать на каком-то уровне надо. Так что стоимость обучения вносится в стоимость продукта :)
                                      • 0
                                        Бизнес и прикладную психологию, а лучше даже клиническую психиатрию!
                                      • 0
                                        Перевод отличный :)
                                        • –5
                                        • +2
                                          хм, все в наших руках и даже самый скучный софт можно сделать с изюменкой и удовольствием.

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

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

                                          в любой «скучной» задаче, как правило много рутинной работы, но что мешает Вам разработать новые методы, которые сократят рутину — в этом то и весь интерес и смак программирования :)

                                          ИМХО
                                          • +4
                                            Так там про это и написано :) Что вместо того чтобы уныло и точно делать ровно то, что просят, программисты начинают извращаться.
                                            • НЛО прилетело и опубликовало эту надпись здесь
                                              • 0
                                                Заказчик ставит вам ТЗ. То, что он не описал в ТЗ, его волновать не должно. Босс опять же может обговорить с вами предстоящую реализацию, но если ему требуется пост-фактум вам говорить, что вы что-то «не так» сделали, то либо что-то не так с вами — непрофессиональное опасное решение или еще не привыкли к принятым в конторе каким-то стандартам и т.п. — или что-то не так с конторой.В любом случае это неверная ситуация.
                                                И вообще я-то пока еще за творческий подход, просто уточняю, что в статье как раз упомянуто то, что вы пытаетесь предлагать)))
                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                  • 0
                                                    Ну так это надо либо обговаривать заранее, если это принципиально, либо принимать как стандарт в конторе, либо как бы оставлять на усмотрение программиста. Если сначала это оставляют вам на откуп, а потом пеняют за «не такую» реализацию, то надо идти к начальству и говорить — давайте сразу пропишем все принципиальные моменты, чтобы в следующие раз ко мне не было таких претензий. Это как раз на мой взгляд абсолютно правильно и логично.
                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                          • 0
                                            Все верно) Про несчем не согласиться)

                                            Но идеология маштабируемости и сложности забита в наших головах!(
                                            • +1
                                              И я поражен этой страшной болезнью…
                                              • –1
                                                То есть все плохо и беспросветно? Ну спасибо, автор стаьи, чтоб ты в аду варился((
                                                • –1
                                                  Ну вот… теперь унылая и скучная работа разработчика будет казаться ещё более унылой и скучной
                                                  • +1
                                                    Каким бы унылым это не казалось, наша работа состоит исключительно в том, чтобы принести прибыль работодателю, а не удовлетворение нам. Вот, что означает быть профессионалом.

                                                    Золотые слова! Можно сколько угодно рвать на себе волосы и орать про китайские и японские винтики, а также «серую массу», но надо четко разделять понятие «профессионализм» и «оригинальность». Если кто-то считает, что написание кода, приносящего прибыль работодателю/заказчику, — это погрязание в серой массе, вы безусловно оригинал, однако не стоит при этом рассчитывать на звание профессионала.
                                                    И еще про японские винтики. Я видел, как в Японии выполняют свою работу, например, обычные смотрители ж/д станций или заправщики вендор-машин… Иначе как совершенством их стиль работы не назовешь. После этого мне стыдно говорить о рутинности моей программисткой деятельности. У программиста, занимающегося даже самой скучной программисткой деятельностью, пространство для достижения совершенства в тысячи раз больше, чем у заправщика вендор-машин. По-моему, программистам поря поумерить то, что Фрэнсис Фукуяма называет «тимосом».
                                                    • 0
                                                      А в чём выражалось это совершенство?
                                                      • 0
                                                        Если описывать подробно, то получится слишком обширный оффтопик. А если вкратце… Ну заправщик вендор-машины, например, раскладывает 30 наименований разных напитков, по полтора десятка банок каждого, минут за 6. Оторваться от этого зрелища совершенно невозможно.
                                                    • +1
                                                      Не хочууу писать скучные программы :(
                                                      • +1
                                                        > В конце дня
                                                        В конце концов

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

                                                          ИМХО, стоит начать с quick&dirty кода, постепенно проводя рефакторинг от проекта к проекту (все-равно общих моментов у многих проектов полно) в итоге и придем к очень элегантному коду.
                                                          • +1
                                                            Только вряд ли нормальный заказчик захочет быть объектом эксперимента. «Тренируйтесь лучше на кошках» (С)
                                                            П.с. Представьте себя у зубного врача с подобным подходом.
                                                            • 0
                                                              Ну собственно, я про это и говорю. Лучше делать все итеративно, то есть работаешь над одним проектов и уже в процессе понимаешь, как можно было сделать лучше, но применяешь это только в следующем проекте.
                                                              • 0
                                                                а что делать? врачами знаете ли тоже сразу не становятся. и рано или поздно те же интерны начинают ставить эксперименты на живых пациентах, точнее тренироваться.
                                                                Так же как и парикмахеры и прочие специальности.
                                                                • 0
                                                                  Во-первых, практиканты делают всё под контролем опытного врача.
                                                                  Во-вторых, нормальный пациент предпочтет лечиться у профессионального врача, а не у практиканта, благо видно сразу, к кому приходишь лечиться.

                                                                  А в примере с парикмахерами — я знаю, где меня могут постричь за 40 рублей (практиканты), но стригусь обычно за 200-250… А туда, где за 40 я не пойду. Потому что хоть и дешевле, но не хочу быть учебным пособием.
                                                                  • 0
                                                                    а я знаю тайное знание где за 120 стригут не практиканты )))

                                                                    но да не в этом дело.
                                                                    Дело в том, что у программистов не развито практически чувство старшего мастера.
                                                                    Мы все сами с усами. И сами рвёмся в бой с пылким взором!
                                                                    В итоге и получается то, что получается.

                                                                    Просто автор пишет о следствиях, тогда как давно пора задуматься о причинах и способах устранения их из ИТшной проф. области.
                                                            • 0
                                                              Всё правильно.
                                                              И мне кажется, что 90% программистов придут к этому пониманию, но спустя лет пять программирования «на заказчика». А оставшиеся 10% останутся в вечных «экспериментаторах», будут придумывать что-то инновационное, но никогда не станут профессиональными _разработчиками_.

                                                              И теперь вопрос — как найти программиста, который подпишется под статьей? :)

                                                              Мне очень нужен хороший RubyOnRails-программист, который понимает и принимает всё вышесказанное :)
                                                              Rак его отличить от программиста, который в проекте «на ходу» меняет языки программирован, подходы, шаблонизаторы, и т.п.? Опытным путем слишком затратно…
                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                              • 0
                                                                В статье банальности, на которые все закрывают глаза и не хотят видеть, но, по себе сужу, чесно следуют.
                                                                • 0
                                                                  Автор написал именно то, в чем я убедился. Респект.
                                                                  Программирование это не исскуство, программирование это ремесло.
                                                                  • +1
                                                                    Может быть это просто две разные вещи? :)
                                                                    Взять, например, кондитеров. Для тех, кто печёт московские плюшки это, может и ремесло, но для истинных кулинаров это искусство.
                                                                    • 0
                                                                      Возможно. Но автор статьи какбы про это и пишет. Зачем нужны истинные кулинары, чтобы печь московские плюшки? Истинным кулинарам нужно тогда быть одиночками и писать свои программы, которые изменят мир и сделают его менее скучным и более вкусным. К сожаление, для индустрии в целом, занимающейся производством плюшек, сегодня нужны скорее автоматы чтобы эти самые плюшки готовить быстрее и больше, чтобы покушать могли все.
                                                                    • 0
                                                                      такое же ремесло как писать картины, например
                                                                      • 0
                                                                        чтобы построить дом художники мало будут полезны, скорее нужны инженеры и архитекторы… ну и строители естественно.
                                                                        • 0
                                                                          В строительстве дома и программисты мало пользы принесут :)
                                                                          • 0
                                                                            Но всетаки ИМХО строительство дома ближе к программированию чем писание картин :-)
                                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                              • 0
                                                                                Все верно, только когда нам нужно строить дом, а дом нам нужно в ИТ строить практически постоянно, то нет иного выхода как сооружать трехмерный принтер из программистов, архитекторов и тестировщиков, которые собственно будут по накатанной работать. Это скучно, не спорю, но заказчику нужен дом, а не остров, который будет и летать и плавать и при этом вместо обычных жителей на нем смогут жить только лапутяне.
                                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                    • –8
                                                                      ИМХО самая толковая статья на хабре за последнюю неделю. Программирование ради программирования должно существовать только как академическая дисциплина для интересующихся. Нет НИКАКОЙ связи между качеством кода и качеством продукта в целом. Обывателю наплевать как программа написана — хоть стадом обезъян котороые танцевали на клавиатуре. Главное что бы продукт:
                                                                      1) не сильно глючил
                                                                      2) не тормозил
                                                                      3) выполнял ожидаемые от него функции.

                                                                      Всякие там рефакторинги, реорганизации, усложнения кода ради никому не нужной гибкости — только для «астронавтов проектирования»

                                                                      Практика показывает что в 80% случаем рефакторинг себя не оправдывает — проще и быстрее ( и дешевле) нагородить хаков поместу нежели перепроэктировать ради получения той же функциональности.
                                                                      • +1
                                                                        Для начала ознакомьтесь с понятием, у вас сильная каша в этом вопросе.
                                                                        • 0
                                                                          Я не описываю понятие рефакторинга — я описываю результат его применения для конечного пользователя и продукта. К рефакторингу зачастую приходят когда архитектура раздувается и новая фича никак не хочет встраиваться в текущую архитектуру. Тогда начинаются обсуждения в духе: все плохо, давайте перепишем, будет кода в 2 раза меньше, а скорость в 2 раза больше и при этом новые фичи будут встраиватся почти на шару.

                                                                          И подобная картина может повторятся раз в 3 — 4 месяца (по мере продвижения продукта с нечетким фичелистом).

                                                                          Так вот, как правило подобная ерунда приводит только одному — увеличению сроков разработки.
                                                                          • +4
                                                                            Это и есть каша. Рефакторинг не проводится время от времени (вернее, конечно, может, но тогда и будет всё как вы описали). Плюс рефакторинг кода — это одно, изменение архитектуры — это другое. А изменение требований — третье. Хороший рефакторинг быстро окупается. А неправильные требования — самая дорогая ошибка.
                                                                      • +1
                                                                        >> чтобы принести прибыль работодателю, а не удовлетворение нам.
                                                                        ИМХО работа профессионального програмиста должна удовлетворять клиента, а профессионализм маркетолога — продать ее с максимальной прибылью.
                                                                        И еще, я сразу предупреждаю школьников — в информатие есть место творчеству в начале и в конце. А посредине есть место только упорству и пунктуальности. Надеюсь они это понимают, когда выбирают профессию.
                                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                                          • +2
                                                                            У вас хорошо получаются переводы; и темы вы выбираете очень интересные! Спасибо! Надеюсь, на продолжение.
                                                                          • +1
                                                                            И еще, все верно, но… насчет третьего правила: почему моя любимая — медик, каждый год на пару недель обкладывается «учебниками», сдает очередные квалификационные экзамены, ей присуждают более высокую степень, прибавляют в зарплате и все это в рабочее время за счет работодателя? И в многих других сферах — это норма.
                                                                            • 0
                                                                              Потому, что от её навыков зависит человеческое здоровье.

                                                                              Вообще, и программисты могут повышать квалификацию за счёт работодателя. Главное объяснить этому работодателю, что ему же выгоднее отправлять сотрудника на семинары для повышения производительности труда.
                                                                              • 0
                                                                                Ххехехех… попадалась статья про ошибки, допущенные при программировании медицинских приборов. Что-то там переполнилось, в результате прибор превысил требуемую интенсивность рентгеновского излучения в стопицот раз, поциент помер через несколько дней. Это если совсем буквально подходить к вопросу о том, от чьих навыков зависит здоровье :)
                                                                          • 0
                                                                            Довольствуйся тем, что есть.

                                                                            Обходись тем, что умеешь.

                                                                            Может быть идеальный программист должен быть буддистом?
                                                                            • +1
                                                                              Дао. Идеальному программисту открывается идеальный код. Но он никогда его не напишет.
                                                                            • 0
                                                                              Жалко, ресурс ru.thedailywtf.org с подобными переводами загнулся.

                                                                              Может автору данного перевода just for fun захочится помочь ребятам с вышеуказанного ресурса в переводе? ;)
                                                                              • 0
                                                                                Что-то даже линк их не открывается…
                                                                                Что касается помощи, то один я весь WTF не потяну, но время от времени мог бы что-то переводить.
                                                                                • 0
                                                                                  Sorry, верно ru.thedailywtf.COM
                                                                              • 0
                                                                                нуу… несколько не соглашусь.

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

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

                                                                                Но рынок (бизнес) стоит во главе стола — это в любом случае правда. Все это знают кроме самих программистов =).
                                                                                • 0
                                                                                  Вообще-то бизнес — это дело. А не рынок, заработок или заказы, или ещё-какая-то-непонятная-хренотень. А дело у каждого может быть своё и может быть разное. И некоторые дела требуют творчества. Собственно, вы можете быть столяром и собирать столы в IKEA на скорость, а можете вырезать статуэтки из дерева. Почему от программистов нужно требовать иного мировозрения? Ну, не хочет человек рутиной заниматься, ну, и фиг с ним. Если он может себе на жизнь не рутиной, так это же прекрасно.

                                                                                  А морали читать с призывами ко всем понижать уровень креативности в работе — это как-то совсем не здорово, imho. Если человек не может успешно креативничать, он сам это скоро поймёт. А если может, то зачем его останавливать?
                                                                                  • 0
                                                                                    вы так мне ответили, будто я придерживаюсь иной точки зрения.
                                                                                • 0
                                                                                  В мемориз однозначно. Красивые фразы из текста распечатаю и повешу на стены, как мотиватор и прозреватор для сотрудников :)
                                                                                  • +2
                                                                                    очень перекликается с Эффективным программистом

                                                                                    В принципе, все очень логично, бизнесу нужен результат в минимальные сроки при минимальных расходах.
                                                                                    Творчеству уделяем свободное время и получаем кайф и скилы:)
                                                                                    • 0
                                                                                      И правда, перекликается :) Спасибо за ссылку.
                                                                                    • 0
                                                                                      А вообще, есть такая (порой даже весьма занятная) книга по теме. 'Рабы Майкрософта' называется.
                                                                                      • +3
                                                                                        Программист — это профессия, которая делает человека счастливым и свободным. Конечно лишь в том случае, если человек — программист по призванию, а не потому, что «так получилось».

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

                                                                                        За примерами далеок ходить не надо: digg, twitter, qip, plentyoffish.com, youtube, myspace и многие многи другие, о которых меньше слышно, но которые делают своих авторов не менее счастливыми. В качестве более земного пример могу привести проект total influence. Afaik, автор начал писать игруху, потому что было интересно. А сейчас ему за это платят.

                                                                                        В общем всё в наших руках. А унылый софт для складского учёта пусть пишут те, кто не согласен :)
                                                                                        • 0
                                                                                          >За примерами далеок ходить не надо: digg, twitter, qip, plentyoffish.com, youtube, myspace

                                                                                          В этих проектах — главное идея, а не техническая реализация. Хотя scaleability у этих проектов отменное!
                                                                                          • +2
                                                                                            Это только со стороны кажется, что главное — идея. Любой, кто довёл хоть один проект с нуля до продакшена, знает, что главное — это реализация. Программистом быть хорошо, потому что реализовать свою идею можно даже в одиночку. А уж в коллективе ещё из двух-трёх увлечённых подельников — тем более.
                                                                                        • +1
                                                                                          Это только со стороны кажется, что главное — идея. Любой, кто довёл хоть один проект с нуля до продакшена, знает, что главное — это реализация. Программистом быть хорошо, потому что реализовать свою идею можно даже в одиночку. А уж в коллективе ещё из двух-трёх увлечённых подельников — тем более.
                                                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                                                            • 0
                                                                                              помнится, один из основателей google(Брин или Пейдж, не помню) говорил, что порядка 20% ресурсов компании уходит в инновации в деятельности. Есть чему поучиться. Т.е. порядка 20-40% личных ресурсов можно/нужно тратить создание sexy-прог. Другими словами — найти свою золотую середину.
                                                                                              • +2
                                                                                                Разработка — процесс, в котором нет предела совершенству. Будь это скучный внутрикорпоративный софт или какой-нить мега-супер-твиттер, которым пользуются миллионы. Поэтому всегда можно писать лучше, красивее, быстрее и качественнее. Налаживать процессы разработки, улучшать интерфейс, использовать прогрессивные технологии и т.п.

                                                                                                Короче, что я хочу сказать: дело не в унылости софта, а в унылости разработчика, если ему работа не в радость.
                                                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                • 0
                                                                                                  И согласна, и не согласна одновременно. «Кодеры-ремесленники» и «программисты-художники» — это только две стороны одной медали. И, чтобы не чувствовать себя «винтиком», никто не запрещает их совмещать.

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

                                                                                                  Я к чему это пишу… у менеджеров своя правда, у нас — своя. Менеджеру ВЫГОДНО сделать нас «винтиками», купить нас с потрохами на полный день, выжимать из нас все соки, не давая даже повышать квалификацию, а когда придут новые технологии, выкинуть нас, как использованную одноразовую посуду. Не ведитесь, господа. Пусть они думают, что мы играем по их правилам, но на деле МЫ продаём им свои услуги, и, в конечном итоге, нам решать. что да как, и, если мы уважаем себя, мы выгадаем и время на саморазвитие, и более интересные проекты. Да, «семь пятниц на неделе» и бесконечные рефакторинги в production-коде — это плохо. Но, в конце концов, никто же не заставляет только этим и заниматься… ;)
                                                                                                  • 0
                                                                                                    Тут ведь речь немного о другом. Не о «винтиках», а о том, что программисты часто склонны «заигрываться» вместо того, чтобы делать реальное дело. И делают это как бы не нарочно.
                                                                                                  • 0
                                                                                                    Я раньше часто менял проекты, искал только интересные, теперь использую работу тупо ради денег, интерес сохраняю для своих личных проектов и для open source, можна сказать что я здался, но так как то проще работать. И все довольны и жена и босс и я
                                                                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                      • +1
                                                                                                        5 пункт вообще, аж прослезился… Есть такое и частенько думаешь — а вот бы кнопочку, чтобы хоп — и написала все :-D

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

                                                                                                        ourCanvas.height = 0; // auto;
                                                                                                        ourCanvas.width = 0; //auto;

                                                                                                        И так строчек 20, гдето на 10 комменты //auto пропадают, а в конце написан коммент, вольный перевод которого звучит примерно так «уфф… ну вроде мы обошли все подводные камни, подложенные нам господами от Микрософт» :-D
                                                                                                        • +1
                                                                                                          в целом верно всё написано, и способность выбрать наиболее эффективный способ реализации адекватный поставленной задачи (сложность, сроки и т.п.) это признак профессионала.

                                                                                                          Но есть одно НО.
                                                                                                          Есть задачи в которых требования меняются со временем. Увеличивается нагрузка посещаемостью, требования по оформлению и т.д. и т.п.
                                                                                                          И чертовски обидно когда приходят и говорят «что же ты зараза сделал всё так плохо, что вот N месяцев спустя у нас ничего не работает». Упуская момент что N месяцев оно всё работало, а сейчас изменились бизнесс требования.
                                                                                                          Архитекторов, например, не заставляют перестроить здание в краткие сроки через пару лет, существенно изменяя изначальные требования.

                                                                                                          Текст написан с одной стороны, и да, нужно быть профессионалом и не увлекаться, когда речь идёт о реальном проекте, реальных деньгах и ограниченном времени.
                                                                                                          Однако, к ИТ специалистам, как к футболистам и политикам, есть такое отношение со стороны народа, что народ всегда знает как сделать лучше. Что фигнёй мы занимаемся и сложного-то ничего в работе нет.
                                                                                                          Вот это заблуждение так же надо искоренять из работодателей, заказчиков и менеджеров. Тогда будут и повышения квалификации и нормальное отношение программистов к выполнению своих обязанностей, без чрезмерного увлечения технологиями.
                                                                                                          У нас же в ИТ порой каждый менеджер «знает как лучше» и «знает как быстрее», о чём обязательно уведомляет программиста, рассказывает ему своё мнение, заставляет выслушать, отъедая тем самым рабочее время, а потом ещё за это же время пеняет, что мол не уложился, дурью маялся.
                                                                                                          • 0
                                                                                                            Интересно вот что — этот перевод статьи о том, что «Программирование — отстой» — залайкали многие читатели Хабра.
                                                                                                            Когда же я говорил о том же: habrahabr.ru/post/218727/ — меня заговнили.
                                                                                                            В чем же дело? Двойные стандарты? Или дело в том, что эта статья не касается личности программиста?

                                                                                                            В любом случае, я рад, что появляются такие статьи, как эта, или как моя, где людям открывают глаза на эту бездонную пучину под названием «программирование». Скольких молодых людей оно съест, проглотит и переварит, покак до них дойдет, что программирование — отстой.

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