Знайте то, что вы хотите сказать

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

Планируйте то, что вы хотите сказать. Напишите «рыбу». Затем спросите себя: "Не противоречит ли это тому, что я пытаюсь высказать?" Совершенствуйте содержание, пока не наступит момент выступления.

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

Знайте вашу аудиторию

Вы общаетесь только в том случае, если передаете информацию. Для этого вам необходимо осознавать потребности, интересы и способности вашей аудитории. Всем нам приходилось присутствовать на собраниях, где нахал-разработчик затуманивает глаза вице-президенту по маркетингу долгим монологом о заслугах некоторой скрытой технологии. Это не общение: это просто разговоры и это утомляет [5].

Составьте устойчивый психологический образ вашей аудитории. Акростих WISDOM, показанный на рисунке 1.1, может помочь в этом.

Например, вы собираетесь предложить интернет-систему, позволяющую конечным пользователям представлять отчеты об ошибках. Об этой системе можно рассказать по-разному, в зависимости от аудитории. Конечные пользователи обрадуются тому, что смогут представлять отчеты об ошибках 24 часа в сутки, не занимая телефона. Отдел маркетинга сможет использовать этот факт в целях увеличения объема продаж. Менеджеры в отделе поддержки будут счастливы по двум причинам: можно будет обойтись меньшим числом сотрудников и генерация отчетов о возникающих проблемах будут автоматизирована. И, наконец, разработчики смогут приобрести опыт в работе с клиент-серверными интернет-технологиями и новым ядром баз данных. Выступая перед каждой из этих групп с отдельной трибуны, вы добьетесь того, что они станут неравнодушными к вашему проекту.

Выбирайте подходящий момент

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

Необходимо уяснить для себя приоритеты аудитории, чтобы лучше понять то, что она хочет услышать от вас. Поймайте менеджера, получившего выговор от шефа, потому что потерялась часть исходного текста программы, и вы найдете в его лице слушателя, который лучше воспринимает ваши идеи о централизованных БД данных исходных текстов. То, что вы говорите, должно быть уместным по времени и содержанию. Иногда для этого достаточно лишь задать вопрос типа: "Удобно ли сейчас поговорить о…?"

What do you want them to learn? (Чему вы хотите их научить)

What is their interest in what you have got to say? (Какова их заинтересованность в вашей речи?)

How sophisticated are they? (Насколько искушена ваша аудитория?)

How much detail do they want? (Насколько детальным должно быть выступление?)

Whom do you want to own the information? (Кто должен обладать информацией?)

How can you motivate them to listen to you? (Как мотивировать слушателей?)

Буквы оригинала складываются в слово «Wisdom» – мудрость (англ.)

Рис. 1.1. Акростих WISDOM – о понимании аудитории

Выбирайте стиль

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

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

Встречают по одежке

Ваши идеи важны. Они заслуживают хорошего способа их подачи вашей аудитории.

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

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

Привлекайте свою аудиторию

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

Умейте слушать

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

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

Обращайтесь к людям

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

Подсказка 10: Важно, что говорить и как говорить

Поскольку вы не работаете в безвоздушном пространстве, вам необходимо уметь общаться. Чем эффективнее это общение, тем более влиятельным вы становитесь.

Связь по электронной почте

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

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

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

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

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

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

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

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

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

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

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

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

Другие разделы, относящиеся к данной теме:

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

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

Вопросы для обсуждения

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

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

Глава 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рассмотрим эти четыре категории дублирования более подробно.

Навязанное дублирование

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

Множественные представления информации. На уровне создания текста программы, нам часто необходимо представить одну и ту же информацию в различных формах. Предположим, мы пишем приложение «клиент-сервер» с использованием различных языков для клиента и сервера и должны представить некоторую общедоступную конструкцию и на первом, и на втором. Возможно, нам необходим класс, чьи атрибуты отражают схему таблицы базы данных. Может быть, вы пишете книгу и хотите включить в нее фрагменты программ, которые вы также хотели бы скомпилировать и протестировать.

Немного изобретательности – и дублирование вам не понадобится. Зачастую ответ сводится к написанию простого фильтра или генератора текста программы. Конструкции с использованием нескольких языков можно собрать из обычного представления метаданных, применяя простой генератор текста программ всякий раз при осуществлении сборки программы (пример этого показан на рисунке 3.4). Определения класса могут быть сгенерированы автоматически из интерактивной схемы базы данных или из метаданных, используемых для построения схемы изначально. Фрагменты программ в этой книге вставлялись препроцессором всякий раз при форматировании текста. Уловка состоит в том, чтобы сделать процесс активным: это не может быть однократным преобразованием, в противном случае мы опять окажемся в положении людей, тиражирующих данные.

Документация в тексте программы. Программистов учат комментировать создаваемый ими текст программы: удачный текст программы снабжен большим количеством комментариев. К сожалению, им никогда не объясняли, зачем тексту программы нужны комментарии: неудачному тексту требуется большое количество комментариев.

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

Документация и текст программы. Вы пишете документацию, затем создаете текст программы. Что-то меняется, и вы исправляете документацию и обновляете текст. И документация, и текст содержат представления одного и того же знания. И все мы знаем, что в суматохе, когда приближается контрольный срок, а важные заказчики высказывают требования, обновление документации стараются отложить.

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

Языковые аспекты. Многие языки навязывают значительное дублирование в исходном тексте программы. Зачастую это происходит, когда язык отделяет интерфейс модуля от его реализации. Языки С и С++ используют файлы заголовка, которые тиражируют имена и печатают информацию о переменных экспорта, функциях и классах (для С++). Язык Object Pascal даже тиражирует эту информацию в том же самом файле. Если вы используете удаленные вызовы процедур или технологию CORBA[URL 29], то при этом происходит дублирование интерфейсной информации в спецификации интерфейса и тексте программы, его реализующей.

Не существует простой методики, позволяющей преодолеть требования языка. В то время как некоторые среды разработки скрывают потребность в файлах заголовка, генерируя их автоматически, а язык Object Pascal позволяет вам сокращать повторяющиеся объявления функции, в общем случае вы используете то, что вам дано. По крайней мере, для большинства языковых аспектов, файл заголовка, который противоречит реализации, будет генерировать некоторое сообщение об ошибке компиляции или компоновки.

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

Неумышленное дублирование

Иногда дублирование происходит в результате ошибок в проекте.

Рассмотрим пример из области транспорта. Пусть аналитик установил, что, наряду с прочими атрибутами, грузовик имеет тип, номерной знак и водителя. Аналогично, маршрут доставки груза представляет собой сочетание маршрута, грузовика и водителя. Мы создаем программы для некоторых классов, основанных на этом представлении.

Но что происходит, если водитель по имени Салли заболевает и приходится менять водителя? Классы Truck и DeliveryRoute содержат описание водителя. Какой из них мы должны изменить? Ясно, что это дублирование неудачно. Нормализуйте его в соответствии с базовой бизнес-моделью – необходим грузовику водитель как часть базового набора атрибутов? А маршрут? Возможно, необходим третий объект, который связывает воедино водителя, грузовик и маршрут. Каким бы ни было окончательное решение, стоит избегать этого типа ненормализованных данных.

Есть не столь очевидный тип ненормализованных данных, который имеет место при наличии множественных взаимозависимых элементов данных. Рассмотрим класс, представляющий отрезок:

class Line {

public:

Point start;

Point end;

double length:

};

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

class Line {

public:

Point start;

Point end;

double length() {return start.distanceTo(end);}

};

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

class Line {

private:

bool changed;

double length;

Point start;

Point end;

public:

void setStart(Point p) {start = p; changed = true;}

void setEnd(Point p) {end = p; changed = true;}

Point getStart(void) {return start;}

Point getEnd(void) {return end;}

double getLength() {

if (changed) {

length = start.distanceTo(end);

changed = false;

}

return length;

}

};

Этот пример также иллюстрирует важный аспект для объектно-ориентированных языков типа Java и С++. Там, где это возможно, всегда используются функции средства доступа – для чтения и записи атрибутов объектов [6]. Это облегчает добавление функциональных возможностей (типа кэширования) в будущем.

Нетерпеливое дублирование

Каждый проект испытывает давление времени – силы, которая может двигать лучшими из нас, заставляя идти напролом. Вам нужна подпрограмма, подобная уже написанной вами? Вас соблазнит возможность копирования и внесения лишь нескольких изменений? Вам нужно значение, чтобы представить максимальное число точек? Если я изменю файл заголовка, целый проект должен быть перестроен. Может, мне просто использовать константы в этом месте?… и в этом… и в том… Нужен класс, подобный тому, который есть в системе поддержки Java? У вас в распоряжении имеется исходный текст, так почему бы просто его не скопировать и не внести необходимые изменения (несмотря на лицензионное соглашение)?

Если вы чувствуете, что поддаетесь искушению, вспомните банальный афоризм: "Тише едешь – дальше будешь". Экономя несколько секунд в данный момент, вы потенциально теряете целые часы. Подумайте об аспектах, относящихся к "проблеме 2000 года". Многие из них были вызваны ленью разработчиков, которые не сделали параметризацию размера полей даты (или не внедрили централизованные библиотеки служб доступа к дате).

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

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

Самый трудный в обнаружении и обработке тип дублирования – коллективный – возникает между различными разработчиками проекта. Целые наборы функциональных возможностей могут тиражироваться по неосторожности, и это дублирование может оставаться незамеченным на протяжении многих лет, что приводит к возникновению проблем при сопровождении. Нам известно, как в одном из штатов США компьютерные системы, установленные в правительственных учреждениях, проверялись на наличие "проблемы 2000 года". Аудиторы обнаружили свыше 10000 программ, каждая из которых по-своему осуществляла проверку правильности номера карточки социального страхования.

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

Мы полагаем, что лучший способ справиться с этим – поощрять активное и частое взаимодействие между разработчиками. Устраивайте форумы для обсуждения общих проблем. (При работе над предыдущими проектами мы организовывали конференции в сети, чтобы позволить разработчикам обмениваться идеями и задавать вопросы. Этим обеспечивается ненавязчивый способ общения – даже на нескольких сайтах – при сохранении непрерывной хронологии всего высказанного). Назначьте одного из членов команды библиотекарем проекта, чьей обязанностью будет обеспечение обмена знаниями. Организуйте специальное место в каталоге с исходными текстами, в котором будут сохраняться сервисные подпрограммы и скрипты. Обратите особое внимание на чтение исходного текста и документации других членов команды, неформально или при анализе текста программы. При этом вы отнюдь не шпионите за ними – вы учитесь у них. И помните, что доступ к тексту программы осуществляется по взаимной договоренности – вас не должно коробить, если и другие члены команды сосредоточенно изучают (или вынюхивают?) ваш текст программы.

Подсказка 12: Сделайте так, чтобы программу можно было легко использовать повторно

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

Другие разделы, относящиеся к данной теме:

• Ортогональность

• Работа с текстом

• Генераторы исходных текстов

• Реорганизация

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

• Вездесущая автоматизация

• Все эти сочинения

Ортогональность

Ортогональность очень важна, если вы хотите создавать системы, которые легко поддаются проектированию, сборке, тестированию и расширению. Однако этому принципу редко обучают непосредственно. Часто он является лишь скрытым достоинством других разнообразных методик, которые вы изучаете. Это неправильно. Как только вы научитесь непосредственно применять принципы ортогональности, вы сразу заметите, как улучшилось качество создаваемых вами систем.

Что такое ортогональность?

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

Этот термин был введен в информатике для обозначения некой разновидности независимости или несвязанности. Два или более объекта ортогональны, если изменения, вносимые в один из них, не влияют на любой другой. В грамотно спроектированной системе программа базы данных будет ортогональной к интерфейсу пользователя: вы можете менять интерфейс пользователя без воздействия на базу данных и менять местами базы данных, не меняя интерфейса.

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

Неортогонольноя система

Предположим, вы находитесь в экскурсионном вертолете, совершающем полет над Гранд-Каньоном, когда пилот, который совершил ошибку, наевшись рыбы за обедом, внезапно вскрикивает и теряет сознание. По счастливой случайности это происходит, когда вы парите на высоте 30 метров. Вы догадываетесь, что рычаг управления общим шагом несущего винта [7] обеспечивает подъем машины, так что, если его слегка опустить, вертолет начнет плавно снижаться. Однако когда вы пытаетесь сделать это, то осознаете, что жизнь – не такая уж простая штука. Вертолет клюет носом, и вас начинает вращать по спирали влево. Внезапно вы понимаете, что управляете системой, в которой каждое воздействие имеет побочные эффекты. При нажатии на левый рычаг вам придется сделать уравновешивающее движение назад правым рычагом и нажать на правую педаль. Но при этом каждое из этих действий вновь повлияет на все органы управления. Неожиданно вам приходится жонглировать невероятно сложной системой, в которой любое изменение влияет на все остальные управляющие воздействия. Вы испытываете феноменальную нагрузку: ваши руки и ноги находятся в постоянном движении, пытаясь уравновесить все взаимодействующие силы.

Органы управления вертолетом определенно не являются ортогональными.