Программист-прагматик. Путь от подмастерья к мастеру

Хант Эндрю

Глава 2

Прагматический подход

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

В этой главе эти идеи и процессы сводятся воедино. Первые два раздела, "Пороки дублирования" и «Ортогональность», тесно связаны между собой. Первый

предостерегает от дублирования знания в ваших системах, второй – от растаскивания единого фрагмента знания по многим компонентам системы.

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

Следующие два раздела также связаны между собой. В разделе "Стрельба трассирующими" говорится о стиле разработки программ, позволяющем одновременно осуществлять сбор требований, тестировать проектные решения и реализовывать текст программы. Если для вас это звучит слишком хорошо, чтобы быть правдой, то так оно и есть: разработки в стиле "Стрельба трассирующими" применимы не всегда. Для последнего случая в разделе "Прототипы и памятные записки" показано, как при тестировании архитектур, алгоритмов, интерфейсов и идей используются прототипы.

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

Ну и наконец, все мы работаем в мире с ограниченным временем и ресурсами. Оба этих недостатка переживаются легче (радуя ваше начальство), если поднатореть в оценке продолжительности какого-либо дела, о чем и говорится в разделе "Оценка".

Держа в голове эти фундаментальные принципы, можно создать программу, которая будет лучше, быстрее и устойчивее. Ее можно даже сделать на вид более простой.

7

Пороки дублирования

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

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

К сожалению, знание нестабильно. Оно изменяется – часто очень быстро. Понимание некоего требования может измениться после встречи с заказчиком. Правительство изменяет административные положения, и некая бизнес-логика устаревает. Тесты могут показать, что выбранный алгоритм не будет работать. Вся эта нестабильность означает, что мы проводим большую часть времени в режиме сопровождения, осуществляя реорганизацию знания и выражая его по-новому в опекаемых нами системах.

Большинство людей полагает, что сопровождение начинается в момент выпуска приложения в свет и означает устранение ошибок и улучшение характеристик. Мы думаем, что эти люди ошибаются. Программисты постоянно находятся в режиме сопровождения. Наше понимание изменяется день ото дня. Новые требования возникают по мере того, как мы проектируем или создаем текст программы. Возможно, изменяется операционная система. Какой бы ни была причина, сопровождение является не дискретным видом деятельности, а рутинной частью процесса разработки в целом.

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

Мы полагаем, что единственно надежным способом разработки программ и облегчения их понимания и сопровождения является следование принципу "Не повторяй самого себя" (Далее DRY = Don't Repeat Yourself. – Прим. пер.):

КАЖДЫЙ ФРАГМЕНТ ЗНАНИЯ ДОЛЖЕН ИМЕТЬ ЕДИНСТВЕННОЕ, ОДНОЗНАЧНОЕ, НАДЕЖНОЕ ПРЕДСТАВЛЕНИЕ В СИСТЕМЕ.

Подсказка 11: Не повторяй самого себя

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

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

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

Как возникает дублирование?

Большинство наблюдаемых явлений дублирования подпадают под одну из следующих категорий:

• Навязанное дублирование. Разработчики чувствуют, что у них нет выбора – им кажется, что дублирования требует среда окружения.

• Неумышленное дублирование. Разработчики не осознают, что они тиражируют информацию.

• Нетерпеливое дублирование. Разработчики ленятся и осуществляют дублирование, потому что им кажется, что так проще.

• Коллективное дублирование. Фрагмент информации тиражируются несколькими членами одной команды разработчиков (или нескольких команд)