Борьба с золотыми правилами программистов

[recoder]

Недавно на ХабраХабре опубликована сатирическая статья "3 простых правила, которые сделают из вас Суперзвезданутого Программиста":

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

Правило 2: Пишите код быстро. Затроньте наибольшее количество файлов, и не забудьте включить каждый из них в ChangeLog. Не беспокойтесь о случайном создании трудно находимых ошибок; они помогут вам в будущем, потому что их, на самом деле, трудно найти. Избегайте создания тривиальных ошибок.

Правило 3: Не тратьте время для документирование кода, или добавления небольших комментариев, объясняющих потенциальные ловушки, связанные с изменением нечетких участков кода. Вам это не нужно – вы пишете код.

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

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

Comments

[oshpaz.livejournal.com]

1. В случае рефакторинга - заметно больше. Все-таки новый код, который надо отлаживать.
2. Согласен на все 100. Общего случая тут нет. Mature code может быть и таким, который менять не надо, и таким, который сильно устарел и тянет все назад.
3. Но это не означает, что надо повсеместно заменять чужой код своим. :)
4. Если знаешь в чем ошибка и ее достаточно просто исправить - зачем стрелять из пушки по воробьям?