Программист-прагматик. Путь от подмастерья к мастеру
Шрифт:
Если есть вероятность, что субподрядчик не справится со своими обязанностями, то у вас должен быть план на случай возникновения непредвиденных обстоятельств. Если жесткий диск выходит из строя, унося в небытие весь исходный текст, а у вас нет резервной копии, это ваша вина. Фраза "Мой исходный текст съел кот Мурзик", высказываемая вашему шефу, не решит возникшей проблемы.
Подсказка 3: Представьте варианты решения проблемы, а не варианты отговорок
Перед тем как подойти к кому-либо, чтобы высказать, почему что-либо не может быть сделано или уже сломалось, остановитесь и прислушайтесь к себе.
Смоделируйте разговор в уме. Что, вероятнее всего, скажет ваш собеседник? Спросит ли он: "А так вы пробовали?" или "А это вы учли?" Как ответить? Перед тем как пойти и сообщить плохие новости, может, попробовать что-то еще? Иногда вы просто знаете, что он собирается сказать, поэтому избавьте его от лишних забот.
Вместо отговорок представьте варианты решения проблемы. Не говорите, что это не может быть сделано, объясните, что может быть сделано для спасения ситуации. Может быть, взять да и выбросить исходный текст? Развивайте эти варианты, используя реорганизацию (см. "Реорганизация"). Стоит ли тратить время на разработку прототипа, чтобы определить лучший способ, который необходимо использовать (см. "Прототипы и памятные записки")? Стоит ли внедрять более совершенные процедуры тестирования (см. "Программа, которую легко тестировать" и "Безжалостное тестирование") или автоматизации (см. "Вездесущая автоматизация"), чтобы предотвратить дальнейшие неудачи? Возможно, вам понадобятся дополнительные ресурсы. Не бойтесь спрашивать или признаться, что нуждаетесь в помощи.
Попытайтесь исключить неубедительные отговорки до того, как их озвучить. Если нужно, выскажите их сначала вашему коту. Ну а если ваш Мурзик возьмет вину на себя…
• Прототипы и памятные записки
• Реорганизация
• Программа, которую легко тестировать
• Вездесущая автоматизация
• Безжалостное тестирование
• Как вы отреагируете, когда кто-нибудь – кассир в банке, механик в автосервисе, или клерк придет к вам с подобными отговорками? Что в итоге можно подумать о них лично и об их фирме?
2
Энтропия в программах
Разработка программного обеспечения обладает иммунитетом почти ко всем физическим законам, однако энтропия оказывает на нас сильное влияние. Энтропия – это термин из физики, обозначающий уровень «беспорядка» в системе. К сожалению, законы термодинамики утверждают, что энтропия во вселенной стремится к максимуму. Увеличение степени беспорядка в программах на профессиональном жаргоне называется "порчей программ".
Существует много факторов, вносящих свой вклад в порчу программ. Похоже, что наиболее важным из них является психология или культура в работе над проектом. Даже если команда состоит лишь из одного-единственного сотрудника, психология проекта может быть весьма тонкой материей. При наличии наилучших планов и специалистов экстракласса, проект все же может рухнуть и сгнить в период разработки. Однако существуют и другие проекты, которые, несмотря на огромные трудности и постоянные неудачи, успешно борются с природной тенденцией к беспорядку и заканчиваются хорошо.
Некоторые здания, расположенные в старых кварталах города, находятся в хорошем состоянии и чистоте, тогда как другие являют собой жуткие развалины. Почему? Исследователи в области преступности и упадка больших городов открыли удивительный механизм, запускающий процесс быстрого превращения чистенького, нетронутого жилого дома в полуразрушенную и заброшенную трущобу [WK82]
Причина – одно-единственное разбитое окно.
Одно разбитое окно, стекло в котором не меняется в течение длительного времени, развивает в обитателях здания ощущение заброшенности – ощущение, что властям нет дела до того, что происходит со зданием. Затем разбивается другое окно. Люди начинают мусорить. На стенах появляются похабные надписи. Возникают серьезные повреждения строительной конструкции. За относительно короткое время здание портится, несмотря на стремление владельца отремонтировать его, и ощущение заброшенности становится реальностью.
"Теория разбитого окна" дала полицейским участкам в Нью-Йорке и других больших городах стимул: навалиться всем миром на решение малых проблем ради сдерживания больших. И это срабатывает: сосредоточение усилий на первоочередном решении проблем разбитых окон, похабных надписей и других малых правонарушений, привело к сокращению уровня тяжких преступлений.
Подсказка 4: Не живите с разбитыми окнами
Не оставляйте "разбитые окна" (неудачные конструкции, неверные решения или некачественный текст программы) без внимания. Как только вы их обнаружите, чините сразу. Если нет времени на надлежащий ремонт, забейте окно досками. Наверняка вы сможете закомментировать ошибочный фрагмент или вывести на экран сообщение "В стадии разработки", или использовать фиктивные данные. Необходимо предпринять хотя бы малейшее действие, чтобы предотвратить дальнейшее разрушение, и показать, что вы контролируете ситуацию.
Мы видели, как безошибочные, функциональные системы быстро портились, как только окна начали разбиваться. Существуют и другие факторы, которые вносят свой вклад в порчу программ, и мы коснемся некоторых из них далее, но небрежность ускоряет порчу быстрее, чем любой другой фактор.
Вы можете подумать, что ни у кого не будет времени обойти "разбитые окна" проекта и отремонтировать их. Если вы продолжаете думать подобным образом, тогда вам лучше спланировать приобретение мусорного контейнера или переехать в другой район города. Не давайте энтропии победить себя.
И напротив, существует история абсурдного (до неприличия) опыта одного из авторов книги, Энди Ханта. Его дом был в идеальном порядке, великолепен, наполнен бесценным антиквариатом, произведениями искусства и прочими ценностями. Однажды гобелен, висевший в гостиной слишком близко от камина, загорелся. Пожарные примчались, чтобы спасти положение, а заодно и дом. Но перед тем как втащить в дом свои большие, грязные шланги, они остановились перед полыхающим огнем, чтобы раскатать специальный мат от входной двери до очага пожара. Они боялись испортить ковер.
Конечно, это весьма экстремальный случай, но именно этот способ должен использоваться в случае с программным обеспечением. Одно разбитое окно – неудачно спроектированный фрагмент программы, неверное решение, принятое менеджером (действующее на протяжении всего проекта) – это все, что требуется дня того, чтобы началось отклонение от нормы. Если оказывается, что вы работаете над проектом с несколькими разбитыми окнами, то слишком легко сползти к умонастроению типа "Вся оставшаяся часть программы – это ерунда, я всего лишь следую примеру". Не важно, в каком состоянии находился проект до этого момента. В оригинальном эксперименте, приведшем к возникновению теории разбитых окон, заброшенный автомобиль стоял в течение недели нетронутым. Но как только одно-единственное окно было разбито, автомобиль был «раздет» и перевернут вверх колесами за несколько часов.