Наши подсказки относительно электронной почты довольно просты:

• Перед тем как щелкнуть мышкой на кнопке SEND (Отправить), тщательно проверьте текст.

• Проверьте правописание.

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

• Используйте форматы RTF или HTML, если вы точно знаете, что все получатели смогут прочесть послание. Простой текст универсален.

• Старайтесь сводить цитирование к минимуму. Никто не любит получать назад свое собственное сообщение в 100 строк, снабженное пометкой "согласен".

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

• Не используйте обидных сообщений, если не хотите, чтобы позже они вернулись, лишив вас покоя.

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

• Архивируйте и организуйте вашу электронную почту – как получаемые, так и отсылаемые материалы.

Как обнаружили служащие фирм Microsoft и Netscape во время расследования Министерства юстиции США (1999 г.), электронная почта – это бессмертно. Постарайтесь заботиться об электронной почте так, как вы заботитесь о любой написанной записке или отчете.

• Прототипы и памятные записки

• Команды прагматиков

• Есть несколько хороших книг, описывающих взаимодействие внутри команд разработчиков [Bro95, МсС95, DL99]. Следует обратить на это особое внимание и попытаться прочесть все три книги течение следующих 18 месяцев. В дополнение к этому, книга "Dinosaur Brains" [Вег96] посвящена эмоциональному багажу, который мы вносим в рабочую среду.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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