На каждого может кто%нибудь напасть: злонамеренный пользователь, беспринципные конкуренты и даже террористы. Разве можно кому%то верить?

Глава 13. Важность проектирования

Вопросы для размышления

1.Как масштаб всей задачи влияет на проект программного обеспечения и работу по его созданию?

Чем больше проект, тем сильнее он нуждается в проектировании архи% тектуры в сравнении с проектированием кода на низком уровне. Боль% ше времени требуется потратить на проектирование на предваритель% ном этапе, поскольку неправильный выбор будет иметь более тяжелые последствия.

2.Что лучше – хорошо документированный плохой проект или плохо до кументированный хороший проект?

Хорошая документация – неотъемлемая часть хорошего проекта. В пло% хом проекте хорошая документация – это путь к коду, даже если это ярко освещенная аллея, ведущая к помойной яме. Она хотя бы пока% жет вам, что этого кода лучше не касаться.

Если код достаточно простой, вам не потребуется объемистая докумен% тация, но если программа сложная, работать с ней в отсутствие при% личного описания становится трудно.

Что лучше? Лучше хороший проект без документации: если проект действительно высокого качества, он должен быть понятен и самодо% кументирован.

3.Как оценить качество проекта по фрагменту кода? Можно ли количе ственно отразить его простоту, элегантность, модульность и т. п.?

Качество трудно измерить; в значительной мере это эстетическая оцен% ка проекта. Почему мы считаем картину прекрасной? Это из разряда тех вещей, которые нельзя взять в руки и пересчитать. Задним числом вы можете оценить, насколько просто оказалось разобраться в коде или модифицировать его. Но впервые столкнувшись с каким%то кодом, трудно его оценить. Если есть две архитектуры, A и B, и мне кажется, что A красивее, но на практике B оказывается удобнее и легче допуска% ет модификацию, то трудно утверждать, что архитектура A лучше.

Опыт полезен в проектировании, поэтому учитесь и применяйте зна% ния на практике. Но проявляйте здравый смысл в отношении своего опыта; не следует действовать автоматически. Разные ситуации вы% двигают разные требования – не следует чрезмерно полагаться на внешнее сходство разных задач.

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

8. Допустимы ли эксперименты в проектировании?

Да, все проекты экспериментальные, пока они не реализованы и не признаны успешными. Возьмите принцип «первый раз делай на вы% брос», описанный Фредериком Бруксом (Brooks 95). В пользу экспери% ментирования можно сказать многое.

Проектирование – итеративный процесс; на каждой итерации можно опробовать альтернативы и выбрать ту, которая наиболее разумна. Чем больше итераций и чем меньше область, охватываемая каждой из них, тем менее болезненными окажутся любые ошибочные проектные решения.

Вопросы личного характера

1.Обратитесь к прошлому и вспомните, как вы учились проектировать код. Смогли бы вы передать полученные вами знания абсолютному но вичку в этом деле?

Сколь многому вы по правде могли бы научить и что должно зависеть от способностей и опыта ученика? Можете ли вы, основываясь на сво% ем опыте, разработать ряд упражнений, которые помогут другим?

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

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

2.Какой опыт у вас есть в использовании конкретных методологий про ектирования? Удачный или неудачный? Каким в результате получил ся код? Какой выбор мог оказаться более удачным?

Остался ли у вас неприятный осадок от прежнего опыта и предпочте% ний? Если вы не умеете применять какую%то методологию, вам будет тяжело и неуютно работать с ней. Матерый C%программист вполне мо% жет невзлюбить любые объектно%ориентированные проекты, а его соб% ственные ОО%конструкции окажутся ужасными. Но это не значит, что OO%программирование – неправильный подход.