Программист-прагматик. Путь от подмастерья к мастеру - страница 10
Подсказка 5: Будьте катализатором изменений
С другой стороны, история с супом из камней – это история о ненавязчивом и постепенном обмане. Это история о шорах на глазах. Крестьяне думают о камнях и забывают обо всем остальном в мире. Все мы впадаем в подобное состояние ежедневно. Нечто просто подкрадывается к нам.
Всем нам известны симптомы. Проекты медленно и неизбежно полностью выходят из-под контроля. Большинство программных катастроф начинаются с малозаметных вещей, и большинство проектов в один прекрасный день идут вразнос. Шаг за шагом система отклоняются от требований, при этом фрагмент текста программы обрастает «заплатами», пока от оригинала не остается ничего. Зачастую именно скопившиеся мелочи приводят к разрушению морали и команд.
Подсказка 6: Следите за изменениями
Сами мы, по чести, никогда этого не делали. Но говорят, что если взять лягушку и бросить ее в кипящую воду, то она сразу выпрыгнет наружу. Однако если бросить лягушку в кастрюлю с холодной водой, а затем медленно нагревать ее, то лягушка не заметит медленного увеличения температуры и останется сидеть в кастрюле, пока не сварится.
Заметим, что проблема лягушки отличается от проблемы разбитых окон, обсуждаемой в разделе 2. В «теории разбитых окон» люди теряют волю к борьбе с энтропией, поскольку она никого не волнует. Лягушка же просто не замечает изменений.
Не будьте лягушкой. Не сводите глаз с общей картины происходящего. Постоянно наблюдайте за тем, что происходит вокруг вас, а не только за тем, что делаете вы лично.
• Энтропия в программах
• Программирование в расчете на совпадение
• Реорганизация
• Западня требований
• Команды прагматиков
• Просматривая черновик данной книги, Джон Лакос поднял следующий вопрос: солдаты постоянно обманывали крестьян, но в результате изменений, катализатором которых они стали, лучше стало всем. Однако, постоянно обманывая лягушку, вы наносите ей вред. Когда вы пытаетесь ускорить изменения, то можете ли определить, варите вы суп из камней или же лягушку? Является ли это решение субъективным или объективным?
4
Приемлемые программы
Для лучшего добро сгубить легко.
У. Шекспир, Король Лир, действие 1, сцена 4
Существует старый анекдот об американской фирме, которая заказала 100000 интегральных схем на предприятии в Японии. В условиях контракта указывался уровень дефектности: один чип на 10000. Несколько недель спустя заказ прибыл в Америку: одна большая коробка, содержащая тысячи интегральных схем, и одна маленькая, в которой находилось десять схем. К маленькой коробке был приклеен ярлычок с надписью «Дефектные схемы».
Если бы у нас был такой контроль качества! Но реальный мир не позволяет производить многое из того, что является действительно совершенным – особенно программы без ошибок. Время, технология и темперамент – все находится в сговоре против нас.
Однако это не должно вас обескураживать. По словам Эда Иордона, автора статьи в журнале IEEE Software [You95], вы можете обучиться созданию приемлемых программ – приемлемых для ваших пользователей, служб сопровождения и с точки зрения вашего же собственного спокойствия. Вы обнаружите, что производительность вашего труда повысилась, а ваши пользователи стали чуть-чуть счастливее. Кроме того, ваши программы станут лучше за счет сокращения инкубационного периода.
Перед тем как пойти дальше, мы должны определиться в том, что собираемся сказать. Фраза «приемлемый» не подразумевает неаккуратную или неудачно написанную программу. Все удачные системы должны отвечать требованиям их пользователей. Мы просто призываем к тому, чтобы пользователям была дана возможность участвовать в процессе принятия решения, если созданное вами действительно приемлемо.
Находите компромисс с пользователями
Обычно вы пишете программы для других людей. Часто вы вспоминаете о том, что хорошо бы получить от них требования [2]. Но как часто вы спрашиваете их, а насколько хорошими они хотят видеть эти программы? Иногда выбирать не из чего. Если вы работаете над передовыми технологиями, космическим челноком, или низкоуровневой библиотекой, которая будет широко распространяться, то требования будут более строгими, а варианты – ограниченными. Но если вы работаете над новым продуктом, то у вас будут ограничения другого рода. Маркетологам придется сдерживать обещания, вероятные конечные пользователи могут строить планы, основанные на дате поставки программы, а ваша фирма, конечно, будет ограничена в денежных средствах. Профессионалы не могут игнорировать требования пользователей – просто добавить к программе новые средства или «отшлифовать» еще раз тексты программ. Мы не призываем к паническим настроениям: одинаково непрофессионально обещать невероятные сроки и срезать основные «технические углы» чтобы уложиться вовремя.
