Борьба с золотыми правилами программистов
Feb. 3rd, 2010 08:28 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
recoderНедавно на ХабраХабре опубликована сатирическая статья "3 простых правила, которые сделают из вас Суперзвезданутого Программиста":
Правило 1: Пишите много кода. Вам нужно исправить небольшую ошибку на участке кода, написанного кем-то другим? Не теряйте времени, пытаясь понять код или мотивацию человека, создавшего его. Просто перепишите большую его часть, и сделайте, чтобы код работал так, как это удобно вам. Назовите это рефакторингом, если, вдруг, кто-то спросит.
Правило 2: Пишите код быстро. Затроньте наибольшее количество файлов, и не забудьте включить каждый из них в ChangeLog. Не беспокойтесь о случайном создании трудно находимых ошибок; они помогут вам в будущем, потому что их, на самом деле, трудно найти. Избегайте создания тривиальных ошибок.
Правило 3: Не тратьте время для документирование кода, или добавления небольших комментариев, объясняющих потенциальные ловушки, связанные с изменением нечетких участков кода. Вам это не нужно – вы пишете код.
Это было бы смешно, если бы не было так грустно. Уже который раз наблюдаю этот самый процесс, и который раз наблюдаю его печальные последствия.
И до сих пор не понимаю, как с этим бороться - что с начинающимся процессом, что с растущей горой последствий. И возможно ли это вообще?
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2010-02-03 06:37 am (UTC)no subject
Date: 2010-02-03 07:30 am (UTC)Только вот в естественный отбор профессионалов я не очень верю. Потому что рынок труда IT - "лимонный".
no subject
Date: 2010-02-03 08:15 am (UTC)no subject
Date: 2010-02-03 08:20 am (UTC)no subject
Date: 2010-02-03 08:39 am (UTC)no subject
Date: 2010-02-03 01:08 pm (UTC)Правило 1(а): Вам нужно исправить небольшую ошибку на участке кода, написанного кем-то другим? Перепишите его часть, и сделайте, чтобы код работал так, как это удобно вам. Назовите это рефакторингом, если, вдруг, кто-то спросит.
Что в нем плохого?
no subject
Date: 2010-02-03 03:23 pm (UTC)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'
no subject
Date: 2010-02-03 03:25 pm (UTC)2. Существующий код уже почищен и отлажен. Mature code - это дело хорошее.
3. После рефакторинга вылезет много багов.
4. Не факт, что рефакторинг исправит изначальную ошибку. :)
no subject
Date: 2010-02-03 07:42 pm (UTC)Крутой программер, не разбирающийся в архитектуре и идеологии того, над чем он работает - будет вести себя как слон в посудной лавке. В лучшем случае он будет мешать коллегам, разбирающимся в теме, а в худшем - наплодит ещё новых багов.
no subject
Date: 2010-02-03 07:43 pm (UTC)no subject
Date: 2010-02-04 09:52 am (UTC)Этот пост – легкая сатира на программирование в составе команды.
При таком раскладе я, пожалуй, соглашусь с тем что 1-е правило это зло, но в отношении индивидуального разработчика, на мой взгляд, оно таковым не является.
no subject
Date: 2010-02-04 09:55 am (UTC)2. Все зависит от того, какого качества этот код. В наиболее общем случае - не факт.
3. Да, баги возможны, но проще ловить баги в своем коде, чем в чужом.
4. А зачем тогда вообще что-то переделывать, если нет четкой концепции исправления ошибки?
no subject
Date: 2010-02-04 03:05 pm (UTC)no subject
Date: 2010-02-04 06:51 pm (UTC)2. Согласен на все 100. Общего случая тут нет. Mature code может быть и таким, который менять не надо, и таким, который сильно устарел и тянет все назад.
3. Но это не означает, что надо повсеместно заменять чужой код своим. :)
4. Если знаешь в чем ошибка и ее достаточно просто исправить - зачем стрелять из пушки по воробьям?
no subject
Date: 2010-02-04 06:52 pm (UTC)