Стив Макконнелл

Алгоритм предоставляет вам сами команды. Эвристика
сообщает вам, как обнаружить команды самостоятельно или по крайней мере где
их искать.

Самая сложная часть программиро#
вания — концептуализация проблемы, и многие ошибки программирования яв#
ляются концептуальными.

Инкрементное проектирование, конструирование и
тестирование — одни из самых эффективных концепций разработки ПО.
При инкрементной разработке вы сначала создаете самую простую версию систе#
мы, которую можно было бы запустить. Она может не принимать реальных дан#
ных, может не выполнять над ними реальных действий, может не генерировать
реальные результаты — она должна быть просто скелетом, достаточно крепким,
ГЛАВА 2 Метафоры, позволяющие лучше понять разработку ПО
15
чтобы поддерживать реальную систему по мере ее разработки. Она может вызы#
вать поддельные классы для каждой из определенных вами основных функций. Такая
система похожа на песчинку, с которой начинается образование жемчужины.
Создав скелет, вы начинаете понемногу наращивать плоть. Каждый из фиктивных
классов вы заменяете реальным. Вместо того чтобы имитировать ввод данных, вы
пишете код, на самом деле принимающий реальные данные. А вместо имитации
вывода данных — код, на самом деле выводящий данные. Вы продолжаете добав#
лять нужные фрагменты, пока не получаете полностью рабочую систему.

Это печально, потому что, если

комбинировании см. раздел 5.3.

вы станете использовать только одну методологию, вы уви#

дите весь мир в терминах этой методологии. В некоторых случаях это сделает

недоступными для вас другие методы, лучше подходящие для решения текущей

проблемы. Метафора инструментария поможет вам держать все методы, способы

и хитрости в пределах досягаемости и применять их в уместных обстоятельствах.

Этот феномен известен как синдром WISCA или WIMP: «Why Isn’t Sam Coding
Anything? (Почему Сэм не пишет код?)» или «Why Isn’t Mary Programming (Почему
Мэри не программирует)?»

Вы можете выбрать более
последовательный подход (при котором вопросы решаются заблаговременно), если:
требования довольно стабильны;
проект приложения прост и относительно понятен;
группа разработчиков знакома с прикладной областью;
проект не связан с особым риском;
34
ЧАСТЬ I Основы разработки ПО
важна долговременная предсказуемость проекта;
затраты на изменение требований, проекта приложения и кода скорее всего
окажутся высокими.
Более итеративный подход (при котором вопросы решаются по мере работы)
можно предпочесть, если:
требования относительно непонятны или вам кажется, что они могут оказать#
ся нестабильными по другим причинам;
проект приложения сложен, не совсем ясен или и то и другое;
группа разработчиков незнакома с прикладной областью;
проект сопряжен с высоким риском;
долговременная предсказуемость проекта не играет особой роли;
затраты на изменение требований, проекта приложения и кода скорее всего
будут низкими.
Как бы то ни было, итеративные подходы эффективны гораздо чаще, чем после#
довательные.

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

Если вы планируете жестко следовать требованиям, на самом деле
вы собираетесь не реагировать на потребности клиента.

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

Исследования, проведенные в IBM и
других компаниях, показали, что при реализации среднего проекта тре#
бования во время разработки изменяются примерно на 25% (Boehm, 1981;
Jones, 1994; Jones, 2000), на что приходится 70–85% объема повторной работы над
типичным проектом (Leffingwell, 1997; Wiegers, 2003).