Хант Эндрю. Программист-прагматик. Путь от подмастерья к мастеру

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

1
Мой исходный текст съел кот Мурзик

   Страх показаться слабым есть величайшая из всех слабостей.

Ж. Б. Боссюэ, Политика и Священное Писание, 1709

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

Принятие ответственности

   Ответственность – это то, на что активно соглашаются. Вы связываете себя обязательством, чтобы гарантировать, что нечто делается правильно, но ваш непосредственный контроль над каждым аспектом делаемого не является необходимостью. В дополнение к тому, что вы делаете все от вас зависящее, необходимо анализировать ситуацию на предмет наличия неконтролируемых вами рисков. Вы имеет право не принимать на себя ответственность за невозможную ситуацию, или за ситуацию, риски в которой слишком велики. Вам придется сделать самоотвод, основанный на вашей собственной этике и оценках.
   Если вы приняли на себя ответственность за результат, то вам придется за него перед кем-то отчитываться. Если вы делаете ошибку (как и все мы), признайте ее честно и попытайтесь предложить варианты исправления.
   Не стоит перекладывать вину на кого-либо (или на что-либо) или выдумывать отговорки. Не стоит сваливать все на субподрядчика, язык программирования, менеджмент или коллег по работе. Все они могут сыграть свою роль в неудаче, но вашим делом является решение проблем, а не отговорки.
   Если есть вероятность, что субподрядчик не справится со своими обязанностями, то у вас должен быть план на случай возникновения непредвиденных обстоятельств. Если жесткий диск выходит из строя, унося в небытие весь исходный текст, а у вас нет резервной копии, это ваша вина. Фраза "Мой исходный текст съел кот Мурзик", высказываемая вашему шефу, не решит возникшей проблемы.
 

   Подсказка 3: Представьте варианты решения проблемы, а не варианты отговорок

 
   Перед тем как подойти к кому-либо, чтобы высказать, почему что-либо не может быть сделано или уже сломалось, остановитесь и прислушайтесь к себе. Поговорите с резиновым утенком, стоящим на вашем мониторе, или с котом. Как звучит ваша отговорка, разумно или глупо? И как ее воспримет ваш шеф?
   Смоделируйте разговор в уме. Что, вероятнее всего, скажет ваш собеседник? Спросит ли он: "А так вы пробовали?" или "А это вы учли?" Как ответить? Перед тем как пойти и сообщить плохие новости, может, попробовать что-то еще? Иногда вы просто знаете, что он собирается сказать, поэтому избавьте его от лишних забот.
   Вместо отговорок представьте варианты решения проблемы. Не говорите, что это не может быть сделано, объясните, что может быть сделано для спасения ситуации. Может быть, взять да и выбросить исходный текст? Развивайте эти варианты, используя реорганизацию (см. "Реорганизация"). Стоит ли тратить время на разработку прототипа, чтобы определить лучший способ, который необходимо использовать (см. "Прототипы и памятные записки")? Стоит ли внедрять более совершенные процедуры тестирования (см. "Программа, которую легко тестировать" и "Безжалостное тестирование") или автоматизации (см. "Вездесущая автоматизация"), чтобы предотвратить дальнейшие неудачи? Возможно, вам понадобятся дополнительные ресурсы. Не бойтесь спрашивать или признаться, что нуждаетесь в помощи.
   Попытайтесь исключить неубедительные отговорки до того, как их озвучить. Если нужно, выскажите их сначала вашему коту. Ну а если ваш Мурзик возьмет вину на себя…

Другие разделы, относящиеся к данной теме:

   • Прототипы и памятные записки
   • Реорганизация
   • Программа, которую легко тестировать
   • Вездесущая автоматизация
   • Безжалостное тестирование

Вопросы для обсуждения:

   • Как вы отреагируете, когда кто-нибудь – кассир в банке, механик в автосервисе, или клерк придет к вам с подобными отговорками? Что в итоге можно подумать о них лично и об их фирме?

2
Энтропия в программах

   Разработка программного обеспечения обладает иммунитетом почти ко всем физическим законам, однако энтропия оказывает на нас сильное влияние. Энтропия – это термин из физики, обозначающий уровень «беспорядка» в системе. К сожалению, законы термодинамики утверждают, что энтропия во вселенной стремится к максимуму. Увеличение степени беспорядка в программах на профессиональном жаргоне называется "порчей программ".
   Существует много факторов, вносящих свой вклад в порчу программ. Похоже, что наиболее важным из них является психология или культура в работе над проектом. Даже если команда состоит лишь из одного-единственного сотрудника, психология проекта может быть весьма тонкой материей. При наличии наилучших планов и специалистов экстракласса, проект все же может рухнуть и сгнить в период разработки. Однако существуют и другие проекты, которые, несмотря на огромные трудности и постоянные неудачи, успешно борются с природной тенденцией к беспорядку и заканчиваются хорошо.

В чем же состоит разница?

   Некоторые здания, расположенные в старых кварталах города, находятся в хорошем состоянии и чистоте, тогда как другие являют собой жуткие развалины. Почему? Исследователи в области преступности и упадка больших городов открыли удивительный механизм, запускающий процесс быстрого превращения чистенького, нетронутого жилого дома в полуразрушенную и заброшенную трущобу [WK82]
   Причина – одно-единственное разбитое окно.
   Одно разбитое окно, стекло в котором не меняется в течение длительного времени, развивает в обитателях здания ощущение заброшенности – ощущение, что властям нет дела до того, что происходит со зданием. Затем разбивается другое окно. Люди начинают мусорить. На стенах появляются похабные надписи. Возникают серьезные повреждения строительной конструкции. За относительно короткое время здание портится, несмотря на стремление владельца отремонтировать его, и ощущение заброшенности становится реальностью.
   "Теория разбитого окна" дала полицейским участкам в Нью-Йорке и других больших городах стимул: навалиться всем миром на решение малых проблем ради сдерживания больших. И это срабатывает: сосредоточение усилий на первоочередном решении проблем разбитых окон, похабных надписей и других малых правонарушений, привело к сокращению уровня тяжких преступлений.
 

   Подсказка 4: Не живите с разбитыми окнами

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

Как погасить пожар

   И напротив, существует история абсурдного (до неприличия) опыта одного из авторов книги, Энди Ханта. Его дом был в идеальном порядке, великолепен, наполнен бесценным антиквариатом, произведениями искусства и прочими ценностями. Однажды гобелен, висевший в гостиной слишком близко от камина, загорелся. Пожарные примчались, чтобы спасти положение, а заодно и дом. Но перед тем как втащить в дом свои большие, грязные шланги, они остановились перед полыхающим огнем, чтобы раскатать специальный мат от входной двери до очага пожара. Они боялись испортить ковер.
   Конечно, это весьма экстремальный случай, но именно этот способ должен использоваться в случае с программным обеспечением. Одно разбитое окно – неудачно спроектированный фрагмент программы, неверное решение, принятое менеджером (действующее на протяжении всего проекта) – это все, что требуется дня того, чтобы началось отклонение от нормы. Если оказывается, что вы работаете над проектом с несколькими разбитыми окнами, то слишком легко сползти к умонастроению типа "Вся оставшаяся часть программы – это ерунда, я всего лишь следую примеру". Не важно, в каком состоянии находился проект до этого момента. В оригинальном эксперименте, приведшем к возникновению теории разбитых окон, заброшенный автомобиль стоял в течение недели нетронутым. Но как только одно-единственное окно было разбито, автомобиль был «раздет» и перевернут вверх колесами за несколько часов.
   К тому же, если вы находитесь в команде и работаете над проектом, тексты программ которого совершенны изначально – корректно написаны, хорошо спроектированы и элегантны – вы, вероятно, предпримете дополнительные усилия к тому, чтобы не испортить их, так как это сделали пожарные с ковром. Даже если речь идет о чрезвычайной ситуации (контрольные сроки, дата выпуска, демонстрационная версия для выставки и т. д.), вы не захотите быть первым среди тех, кто портит проект.

Другие разделы, относящиеся к данной теме:

   • Суп из камней и сварившиеся лягушки
   • Реорганизация
   • Команды прагматиков

Вопросы для обсуждения

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

3
Суп из камней и сварившиеся лягушки

   Трое солдат возвращались с войны и проголодались. Когда они увидели впереди деревню, их настроение поднялось – они были уверены, что крестьяне накормят их. Но как только они пришли в деревню, все двери оказались заперты, а окна – закрыты. После долгой войны крестьяне бедствовали и прятали все, что у них есть.
   Это не смутило солдат, они вскипятили котел воды и аккуратно положили в него три камня. Удивленные крестьяне вышли посмотреть.
   "Это суп из камней", – объяснили солдаты крестьянам. "И это все, что вы в него кладете?" – спросили крестьяне. "Абсолютно все – хотя на вкус он будет намного лучше, если положить в него немного моркови". Один из крестьян убежал и быстро вернулся с корзиной моркови из своего погреба.
   Через некоторое время крестьяне вновь спросили: "И это все?"
   "Да", – сказали солдаты, "но пара картофелин сделает суп посытнее", И другой крестьянин убежал.
   В течение следующего часа солдаты попросили у крестьян другие ингредиенты, которые сделали суп вкуснее: мясо, лук, соль и травы. И каждый раз крестьяне потрошили свои запасы.
   Так они сварили большой котел дымящегося супа. Затем солдаты вынули камни и уселись вместе со всей деревней, чтобы поесть досыта – первый раз за многие месяцы.

   В истории с супом из камней есть два важных урока. Солдаты обманывали крестьян, используя любопытство последних, чтобы добыть у них пищу. Но что более важно, солдаты явились катализатором, объединяя жителей деревни с тем, чтобы общими усилиями сделать то, что они не смогли сделать сами, – синергетический результат. В конечном итоге выигрывают все.
   Иногда в этой жизни вам бы хотелось оказаться на месте солдат.
   Вы можете оказаться в ситуации, когда вам точно известно, что нужно сделать и как это сделать. Перед глазами возникает общий план системы, и вы осознаете, что именно так это и должно быть. Но если вы попросите разрешения на проработку аспекта в целом, то столкнетесь с волокитой и пустыми глазами. Люди будут образовывать комиссии, бюджет должен быть одобрен, и все будет усложнено. Каждый будет держаться за свое кресло. Иногда это называется "изначальной усталостью". Пора вытаскивать камни из котла. Выработайте то, о чем вы реально можете попросить. Проработайте детали. Как только вы это сделаете, покажите людям и позвольте им удивиться. Они скажут: "Конечно, было бы лучше, если бы мы добавили". Положим, что это не важно. Расслабьтесь и подождите, пока они не начнут спрашивать вас о добавлении функциональных возможностей, которые вы задумали изначально. Людям легче присоединиться к грядущему успеху. Покажите им свет в конце туннеля, и они сплотятся вокруг вас [1].
 

   Подсказка 5: Будьте катализатором изменений

 
   С другой стороны, история с супом из камней – это история о ненавязчивом и постепенном обмане. Это история о шорах на глазах. Крестьяне думают о камнях и забывают обо всем остальном в мире. Все мы впадаем в подобное состояние ежедневно. Нечто просто подкрадывается к нам.
   Всем нам известны симптомы. Проекты медленно и неизбежно полностью выходят из-под контроля. Большинство программных катастроф начинаются с малозаметных вещей, и большинство проектов в один прекрасный день идут вразнос. Шаг за шагом система отклоняются от требований, при этом фрагмент текста программы обрастает «заплатами», пока от оригинала не остается ничего. Зачастую именно скопившиеся мелочи приводят к разрушению морали и команд.
 

   Подсказка 6: Следите за изменениями

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

Другие разделы, относящиеся к данной теме:

   • Энтропия в программах
   • Программирование в расчете на совпадение
   • Реорганизация
   • Западня требований
   • Команды прагматиков

Вопросы для обсуждения

   • Просматривая черновик данной книги, Джон Лакос поднял следующий вопрос: солдаты постоянно обманывали крестьян, но в результате изменений, катализатором которых они стали, лучше стало всем. Однако, постоянно обманывая лягушку, вы наносите ей вред. Когда вы пытаетесь ускорить изменения, то можете ли определить, варите вы суп из камней или же лягушку? Является ли это решение субъективным или объективным?

4
Приемлемые программы

   Для лучшего добро сгубить легко.

У. Шекспир, Король Лир, действие 1, сцена 4

   Существует старый анекдот об американской фирме, которая заказала 100000 интегральных схем на предприятии в Японии. В условиях контракта указывался уровень дефектности: один чип на 10000. Несколько недель спустя заказ прибыл в Америку: одна большая коробка, содержащая тысячи интегральных схем, и одна маленькая, в которой находилось десять схем. К маленькой коробке был приклеен ярлычок с надписью "Дефектные схемы".
   Если бы у нас был такой контроль качества! Но реальный мир не позволяет производить многое из того, что является действительно совершенным – особенно программы без ошибок. Время, технология и темперамент – все находится в сговоре против нас.
   Однако это не должно вас обескураживать. По словам Эда Иордона, автора статьи в журнале IEEE Software [You95], вы можете обучиться созданию приемлемых программ – приемлемых для ваших пользователей, служб сопровождения и с точки зрения вашего же собственного спокойствия. Вы обнаружите, что производительность вашего труда повысилась, а ваши пользователи стали чуть-чуть счастливее. Кроме того, ваши программы станут лучше за счет сокращения инкубационного периода.
   Перед тем как пойти дальше, мы должны определиться в том, что собираемся сказать. Фраза «приемлемый» не подразумевает неаккуратную или неудачно написанную программу. Все удачные системы должны отвечать требованиям их пользователей. Мы просто призываем к тому, чтобы пользователям была дана возможность участвовать в процессе принятия решения, если созданное вами действительно приемлемо.

Находите компромисс с пользователями

   Обычно вы пишете программы для других людей. Часто вы вспоминаете о том, что хорошо бы получить от них требования [2]. Но как часто вы спрашиваете их, а насколько хорошими они хотят видеть эти программы? Иногда выбирать не из чего. Если вы работаете над передовыми технологиями, космическим челноком, или низкоуровневой библиотекой, которая будет широко распространяться, то требования будут более строгими, а варианты – ограниченными. Но если вы работаете над новым продуктом, то у вас будут ограничения другого рода. Маркетологам придется сдерживать обещания, вероятные конечные пользователи могут строить планы, основанные на дате поставки программы, а ваша фирма, конечно, будет ограничена в денежных средствах. Профессионалы не могут игнорировать требования пользователей – просто добавить к программе новые средства или «отшлифовать» еще раз тексты программ. Мы не призываем к паническим настроениям: одинаково непрофессионально обещать невероятные сроки и срезать основные "технические углы" чтобы уложиться вовремя.
   Сфера действия и качество создаваемой вами системы должны указываться в части системных требований.
 

   Подсказка 7: Сделайте качество одним из пунктов требований

 
   Часто вы будете оказываться в ситуациях, когда необходимо идти на компромисс. Удивительно, но многие пользователи предпочтут использовать программы с некоторыми недоработками, но сегодня, чем год ожидать выпуска мультимедийной версии. Многие IT-департаменты, имеющие ограничения по бюджету, могли бы согласиться с этим утверждением. Хорошие программы (но сегодня) зачастую являются более предпочтительными по сравнению с отличными программами (но завтра). Если вы заранее дадите другим пользователям поиграться с вашей программой, то часто их отзывы будут способствовать выработке лучшего конечного решения (см. "Стрельба трассирующими").

Знайте меру

   В ряде случаев программирование подобно живописи. Вы начинаете с чистого холста и определенных базовых исходных материалов. Используете сочетание науки, искусства и ремесла, чтобы определить, что же делать с ними. Набрасываете общую форму, выписываете основу, затем работаете над деталями. Постоянно отступаете назад, чтобы критически взглянуть на то, что же вы сделали. Иногда отбрасываете холст и начинаете снова.
   Но художники скажут вам, что вся тяжелая работа идет насмарку, если вы не знаете, в какой момент нужно остановиться. Если вы добавляете слой за слоем, деталь за деталью, живопись может потеряться в краске.
   Не стоит портить очень хорошую программу путем приукрашивания и излишней шлифовки. Двигайтесь вперед и дайте вашей программе отстаивать свои права в течение какого-то времени. Она может быть несовершенной. Не беспокойтесь, возможно, она никогда не станет совершенной. (В главе 6 мы обсудим философию разработки программ в несовершенном мире.)

Другие разделы, относящиеся к данной теме:

   • Стрельба трассирующими
   • Западня требований
   • Команды прагматиков
   • Большие надежды

Вопросы для обсуждения

   • Обратите внимание на производителей инструментальных программных средств и операционных систем, которыми вы пользуетесь. Можете ли вы найти свидетельство тому, что эти компании не испытывают неудобства, поставляя программное обеспечение, хотя им известно, что оно несовершенно? Как пользователь, вы скорее: (1) подождете, пока они устранят все ошибки, (2) выберете усложненную версию программы и примете отдельные ошибки или (3) выберете упрощенную версию программы, но с меньшим числом дефектов?
   • Рассмотрите эффект разбиения на модули при поставке программного обеспечения. Больше или меньше времени потребуется для доведения монолитного программного блока до требуемого уровня качества по сравнению системой, спроектированной по модульному принципу? Можете ли вы привести коммерческие примеры?

5
Портфель знаний

   Инвестиции в знания окупаются лучше всего.

Бенджамин Франклин

   Ах, старина Франклин! Никогда не лез в карман за многозначительным наставлением. Если бы мы рано ложились и рано вставали, мы стали бы великими программистами, не так ли? Ранняя птичка никогда не остается без червячка, но что при этом происходит с червячком?
   Хотя в данном случае Бенджамин действительно попал в точку. Знание и опыт являются самыми важными профессиональными активами.
   К сожалению, знания и опыт представляют собой истекающие активы [3]. Ваше знание устаревает по мере того, как разрабатываются новые методики, языки, технологии и операционные среды. Изменение расстановки сил на рынке может сделать ваш опыт устаревшим или полностью неприменимым. Принимая во внимание скорость, с которой промчались годы Интернета, это может произойти довольно быстро.
   По мере того как величина ваших знаний уменьшается, то же самое происходит с ценностью вас для фирмы-работодателя или заказчика. Мы хотели бы предотвратить возникновение подобной ситуации.

Ваш портфель знаний

   Портфелями знаний мы предпочитаем называть все факты, известные программистам об информатике, области приложений, в которых они работают, и накопленный ими опыт. Управление портфелем знаний очень похоже на управление финансовым портфелем:
   1. Серьезные инвесторы инвестируют регулярно – это как привычка.
   2. Диверсификация – это залог успеха в течение длительного времени.
   3. У проворных инвесторов портфель всегда сбалансирован – в нем имеются и консервативные, и высокорисковые, высокодоходные инвестиции.
   4. Инвесторы стараются покупать ценные бумаги подешевле и продавать их подороже, обеспечивая тем самым максимальный возврат.
   5. Портфели нуждаются в периодическом пересмотре и повторной балансировке.
   Управляйте вашим портфелем знаний, используя те же самые принципы, и ваша карьера будет успешной.

Построение вашего портфеля

   •  Инвестируйте на регулярной основе.Как и в случае финансов, необходимо регулярно инвестировать в ваш портфель знаний. Даже если объем инвестиций невелик, сама по себе привычка важна, как, впрочем, и объемы. Несколько примеров на эту тему приводятся в следующем разделе.
   •  Инвестируйте в различные сферы.Чем больше вы знаете о различных вещах, тем большую ценность вы представляете. Как минимум вы обязаны знать плюсы и минусы конкретной технологии, с которой вы работаете в данный момент. Но не останавливайтесь на этом. Лицо информатики меняется быстро – новейшая технология сегодняшнего дня может оказаться почти бесполезной (или, по меньшей мере, не найти спроса) завтра. Чем больше технологий вы освоите, тем легче вам будет приспособиться к изменениям.