Прежде всего, не навреди

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

Иногда программисты изменяют части программ лишь только потому, что им не нравится как выглядит ее код. Это плохо. Если вы не знаете всех частей программы, затрагиваемых изменением (а это почти невозможно), то не трогайте код. Вы можете вполне резонно возразить, что на самом деле ни одно из, изложенных выше, не относится к сопровождению программ. Вы просто не сможете изменить существующий код программы в соответствии с каким-то методическим руководством (как бы вам этого ни хотелось), без риска нанести ей непоправимый ущерб. Предлагаемые здесь правила полезны лишь только тогда, когда y вас есть блестящая возможность начать программу с нуля.

Малое это прекрасно. (Большое == медленное)

Распухание программ является огромной проблемой. В стародавние времена OC’ы работали на 16-разрядной шине с 64Кбайтами внутренней памяти. В наше время большинство операционных систем требуют 32-разрядных машин с минимум 16 Мбайтами оперативной памяти, чтобы работать с приемлемой скоростью. Очевидно, что большая часть этого распухания памяти является результатом небрежного программирования.

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

Третьей проблемой является модульность. Одно из фундаментальных положений гласит — «меньше — лучше». Большие задачи лучше выполняются взаимодействующей системой небольших модульных программ, каждая из которых хорошо исполняет лишь одно задание, но каждая из них может сообщаться с другими компонентами. (Стандарт связи и внедрения объектов Microsoft (OLE) добавляет это свойство в Windows, а OpenDoc— в Macintosh.) Если ваше приложение представляет собой модульную конструкцию из маленьких программ, работающих вместе, то вашу программу очень просто настраивать по заказу путем смены модулей. Если вам не нравится этот редактор, то поменяйте его на новый.

Наконец, программы обычно уменьшаются в процессе усовершенствования. Большие программы, вероятно, никогда не подвергались усовершенствованиям.

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

Заказчик всегда прав

Ни одной программе не добиться успеха, если ее проектировщики не общаются непосредственно с ее конечными пользователями. Несмотря на это, часто ситуация больше напоминает игру («испорченный телефон»), в которую многие из нас играли в детском саду, когда 20 ребятишек садятся в кружок. Кто-нибудь шепчет фразу своему соседу (соседке), который передает ее своему, и так далее по кругу. Забава заключается в том, чтобы послушать как сообщение звучит после того, как пройдет весь круг — обычно ничего похожего на исходную фразу. Тот же самый процесс зачастую встречается при разработке программ. Пользователь говорит с управляющим, докладывающим другому управляющему, который нанимает консультационную фирму. Президент консультационной фирмы разговаривает с руководителем разработчиков, который в свою очередь говорит со старшим группы, обращающимся наконец к программистам. Шансы на то, что даже простой документ с требованиями останется после этого процесса невредимым, равны нулю. Единственным решением этой проблемы является тесное вовлечение пользователей в процесс разработки, лучше всего путем включения по крайней мере одного конечного пользователя в команду разработчиков.

Родственная ситуация складывается в случае простой самонадеянности части программистов, которые говорят: «Я знаю, что пользователи сказали, что им нужно сделать это таким-то способом, но у них нет достаточных знаний о компьютерах, чтобы принять сознательное решение; мой способ лучше». Такое отношение фактически гарантирует, что программой никогда не будут пользоваться. Исправить ситуацию здесь можно, официально назначив конечного пользователя лицом, оценивающим качество проекта. Никто не может начать писать код до тех пор, пока пользователь-член команды не даст на это добро. Сотрудники, игнорирующие проект в пользу своих идей, должны быть уволены. В реальной жизни для подобного типа детского упрямства на самом деле нет места.

При этом нужно сказать, что опытный проектировщик зачастую предлагает лучшее решение проблемы, чем придуманное конечным пользователем, в особенности, если учесть, что конечные пользователи часто предлагают интерфейсы, созданные по образцу прoграмм, которыми они постоянно пользуются. Несмотря на это, до начала реализации вы должны убедить пользоваться в том, что ваш способ лучше. «Лучший» интерфейс не является лучшим, если никто, кроме вас, не сможет (или не захочет) им пользоваться.

Компьютерное программирование является индустрией обслуживания

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

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

Легко увидеть, как возникает эта печальная ситуация: программисты создают программы, которые никому не нужны. Исправить ее тоже легко, хотя в определенном окружении это и сталкивается с неожиданными трудностями: спросите людей, что им нужно, и затем сделайте то, что они вам сказали.

К сожалению, многие программисты производят впечатление лиц, полагающих, что конечные пользователи не знают чего хотят. Вздор. Почти всегда пользователи оказываются так запуганы сыплющим специальными терминами «экспертом», что замолкают. Мне часто говорили: «Я знаю, что мне нужно, но не могу это выразить». Лучший ответ на это: «Отлично, скажите это на нормальном языке — я сделаю перевод на компьютерный».

Проблема должна быть хорошо продумана перед тем, как она сможет быть решена

Эти правила посвящены весьма реальным проблемам и во многих отношениях являются самыми важными правилами в этой книге.

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

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

Кроме того, скверно спроектированные программы труднее реализовать. Тот аргумент, что у вас нет времени на проектирование, потому что вы «должны захватить рынок программ как можно скорее», просто не выдерживает никакой критики, потому что реализация плохого (или никакого) проекта требует гораздо больше времени.