Нельзя измерять свою производительность числом строк

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

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

К сожалению, в отчетных документах это выглядит впечатляюще, когда кто-то пишет программу быстро, но не думает при этом о ее сопровождении или элегантности. «Ого, она выдает в два раза больше кода вдвое быстрее». Учтите, что какой-то несчастный программист, сопровождающий задачу, будет затем вынужден потратить в восемь раз больше времени, сокращая первоначальный размер программы наполовину и делая ее пригодной для использования. Число строк кода в день, как мера объема, не является мерилом производительности.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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