Пишите программу с учетом сопровождения — сопровождаюшим программистом являетесь вы сами

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

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

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

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

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

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

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

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