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