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

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

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

16. Редактируйте свою программу

1 7. Программа должна быть переписана не менее двух раз

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

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

Имейте в виду, что редактирование должно быть сделано по окончании, потому что неотредактированный текст программы, по сути,

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

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

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

1 9. Вы не можете программировать в изоляции

Классическая книга Джеральда Уэйнберга "The Psychology of Computer Programming" (New York: Van Nostrand Reinhold, 1971) содержит великолепную историю об автоматах с газированной водой. Администрация одного вычислительного центра решила, что слишком много времени растрачивается сотрудниками у автоматов с газированной водой. Люди создают много шума и ничего при этом не делают, поэтому автоматы убрали. Через несколько дней консультанты на местах были настолько перегружены работой, что к ним стало невозможно обратиться. Мораль состоит в том, что люди совсем не зря растрачивали время: оказывается, издавая весь этот шум, они помогали друг другу в решении проблем.

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

20. Пустые потери времени

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

Я был студентом в те древние времена, когда персональным компьютером был Apple I, а серьезные студенты-программисты владели коробками S-100, которые вы программировали, вводя двоичные команды переключателями лицевой панели по одному байту за раз. (Если вы были счастливчик, то имели интерпретатор языка БЕЙСИК и терминал, сделанный из старого телевизора). Студенты делили PDP 11/70, работавшую под UNIX (которая отлично работала на 16-битовой машине с 64 Кбайт памяти - Боже мой! Как все с тех пор усовершенствовалось). О возможности использования персонального компьютера для выполнения домашних заданий не было и речи.

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

Такая обстановка, конечно, не способствовала хорошо продуманному проектированию программ, поэтому большинство из этих программ были в четыре раза больше, чем необходимо, и требовали в два раза больше времени на отладку, чем требовалось. К тому же, количество строк кода, написанное за час, сокращается пропорционально количеству часов, которые вы просидели, глядя на экран. (Это иллюзия - думать, что вы можете достичь большей производительности, работая 1 2 часов в день вместо 8).

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