Как проектировать код

Всегда проектируйте вещь, рассматривая ее в ближайшем контексте: стул – в комнате,

комнату – в здании, здание – в окружающей среде, окружающую среду – в плане развития города.

Элиэль Сааринен

Как научиться правильно проектировать? Хорошими проектировщи% ками становятся или рождаются? Можно ли обучать проектированию и можно ли перенять это искусство? У программистов бывает природ% ное чутье на хороший проект; так устроены их мозги. Они от природы эстетически развиты и способны в достаточной мере разобраться в про% блеме, чтобы выносить здравые суждения. Тем не менее эффективно% му проектированию можно научиться.

Лично у меня от рождения не было особого таланта в гончарном ремес% ле. (И я не встречал людей, у которых он был.) Я и сейчас не добился в этом больших успехов, но одно время учился этому делу. Я понял ме% ханизм и могу делать горшки (почти самобытные). Вероятно, попрак% тиковавшись, я преуспел бы больше, но мастером%художником мне никогда не стать.

Точно так же никто не рождается с природными способностями к про% ектированию кода. Нужно учиться. Учиться методологиям проекти% рования и хорошим техническим приемам. Их цель – сделать проек% тирование воспроизводимым процессом, но они не заменят мастерст# во. Творческое мышление и способность к новаторским проектам пере% дать гораздо сложнее; всегда будут талантливые проектировщики, которым это дается легко.

Хороший проект программного обеспечения эстетически привлекате% лен; для создания этих цифровых произведений искусства нужны мас% терство, опыт и практика. Я не буду пытаться описать, как проектиро% вать программы, подобно тому, как учат рисовать по клеточкам. Жаль: умей я разливать хорошие проекты по бутылкам, можно было бы стать миллионером. Чтобы научиться хорошо проектировать, нуж% но понять, что составляет хороший проект и каковы признаки плохого проекта. Затем практиковаться. Долго.

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

Методы и процедуры проектирования

Существует много методологий проектирования программного обеспе% чения. В одних подчеркивается система обозначений, в других – про% цедура. Систематический подход лучше, чем проектирование как бог

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

Современные методы проектирования делятся на две основные груп% пы в соответствии со своей базовой философией проектирования:

Структурное проектирование

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

Два основных подхода составляют нисходящее (top#down) и восходя# щее (bottom#up) проектирование.

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

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

На практике оба подхода применяются в паре, и процесс проекти% рования завершается, когда они встречаются между собой где%то посередине.

Объектно ориентированное проектирование

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

При OO%проектировании выделяются основные объекты предмет% ной области и устанавливаются их характеристики. Задается пове% дение этих объектов, в том числе операции, которые они могут осу% ществлять, и взаимодействие с другими объектами. Эти объекты включаются в проект вместе со всеми необходимыми объектами об% ласти реализации. Проектирование завершается после определе% ния поведения и взаимодействия всех объектов.

1Э. Гамма, Р. Хелм, Дж. Ральф, В. Джон «Приемы объектно%ориен% тированного проектирования. Паттерны проектирования». – Пер. с англ. – СПб.: Питер, 2006.

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

Более подробное описание методов и процедур проектирования см. в разделе «Стили программирования» на стр. 530.

Инструменты проектирования

Проект в конечном итоге находит свое выражение в коде, но часто ока% зывается полезным работать на более абстрактном уровне. Задача ин% струментов – помочь нам обдумывать проекты, создавать более эффек% тивные проекты и сообщать об этих проектах программистам посред% ством документации, описывающей то, что мы намерены изготовить и что уже сделано.

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

Нотация

Хорошая картинка стоит многих слов. Многочисленные системы графических обозначений помогают выражать наши проекты на% глядным образом. Большинство из них оказывается преходящей модой и быстро исчезает из виду, чтобы уступить место еще более привлекательному способу рисовать окошечки и соединять их ли% ниями. В данное время самой популярной и проработанной систе% мой обозначений является UML (Unified Modeling Language – уни# фицированный язык моделирования). Она позволяет моделировать и документировать практически все объекты, создаваемые в про% цессе разработки программного обеспечения. В процессе развития ее полнота стала такова, что возможности визуализации более не ограничиваются программным обеспечением; она применяется для моделирования аппаратных средств, бизнес%процессов и даже орга% низационных структур.

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

•Быстро набросать проект «на манжетах» и выразить свои мысли на доске.

•Формально описать проект.

В последнем случае вычерчивание диаграмм должно происходить автоматически с помощью специального графического средства. Иначе диаграммы будет сложно обновлять, и по мере разработки кода они начнут устаревать. Свое время нужно тратить более эф% фективно, чем на вычерчивание прямоугольников и линий.

Я предпочитаю не увязать глубоко в формальном применении этой нотации, а пользоваться ею как средством изложения важных эле% ментов проекта. Мне достаточно того, что я могу описать свои идеи, а вникать в смысл всяких звездочек и пунктирных линий в отдель% ных типах диаграмм мне недосуг.