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

[recoder]

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

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

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

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

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

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

Comments

[zubian.livejournal.com]

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

[recoder]

Известно, что путь офисного самурая - увольнение.

Только вот в естественный отбор профессионалов я не очень верю. Потому что рынок труда IT - "лимонный".

[zubian.livejournal.com]

Я конечно пошутил :) На самом деле, это не техническая проблема, а управленческая. Лимонный рынок - некомпетентные менеджеры как правило не в состоянии отличить профессионального программиста, от профессионального - а поскольку первые зачастую рапортуются куда более эффективно чем последние, то имеем что имеем. Выход - увольнять на...й всех топ-псевдо-менеджеров и назначать компетентных людей. Но до осознания этого ещё не скоро дойдут.

[recoder]

Ну с тем, кто виноват, мы определились. Остался исходный вопрос: что делать?

[zubian.livejournal.com]

Становится топ-менеджером :)

[nepalich.livejournal.com]

Немного видоизменим правило 1, убрав из него лишние эпитеты:

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

Что в нем плохого?

[oshpaz.livejournal.com]

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

[nepalich.livejournal.com]

1. Оно тратится в любом случае.
2. Все зависит от того, какого качества этот код. В наиболее общем случае - не факт.
3. Да, баги возможны, но проще ловить баги в своем коде, чем в чужом.
4. А зачем тогда вообще что-то переделывать, если нет четкой концепции исправления ошибки?

[oshpaz.livejournal.com]

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

[recoder]

Ну можно вообще все отрицательные оценки убрать. А можно ещё положительных добавить. Суть от этого не изменится.

Крутой программер, не разбирающийся в архитектуре и идеологии того, над чем он работает - будет вести себя как слон в посудной лавке. В лучшем случае он будет мешать коллегам, разбирающимся в теме, а в худшем - наплодит ещё новых багов.

[nepalich.livejournal.com]

В статье, на которую Вы даете ссылку говорится:
Этот пост – легкая сатира на программирование в составе команды.

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

[recoder]

Индивидуальный разработчик - сам себе аналитик, архитектор, кодер, тестер и в общем случае - сам себе злобный буратино. Но мы не говорим не о сферических конях в ваккуме, а о промышленной разработке софта.

[oshpaz.livejournal.com]

У нас за такое можно серьезных звиздюлей от коллег заработать. :)

[recoder]

Кстати - разницу между рефакторингом и "переписать код под себя" надо объяснять?

[(Anonymous)]

nu 'eto odna iz taktik - napisat' tak chtob tol'ko ti mog chinit' esli slomaets'a, v rezul'tate - ti ne zamenimii dl'a kompanii :)
a borots'a s 'etim mojno s pomo'sh'u 'code changes reviews' (kogda vse izmeneni'a v kode v ob'azatel'nom por'adke prover'auts'a team leadom i doverennimi senior developer'ami). libo mojno 'eto urezat' do slejki za tol'ko podozritel'nimi progerrami a horoshih mojno ne prover'at'