...Или что-то вроде того.

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

Я знаю, что вы думаете. Всех, кто так говорит — и уж тем более пишет такое в блогах — нужно немедленно лишить их программерской лицензии, отобрать у них клавиатуры и навечно посадить за микроЭВМ с 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-корпораций.

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

Оригинал: http://thedailywtf.com/Articles/Program … t-To-.aspx
Перевод: 21csm (http://21csm.com)

ВОПРОС
Кто что об этом думает? Мне вот рассылкой с rsdn пришло... имхо пахнет немного бред'ом