Сроду такого не было, и опять то же самое.

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

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

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

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

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