Перевод статьи «Advice to programmers: If it works, don’t fix it. Or?».
Представьте то программное обеспечение, над которым вы работаете. Оно было написано другими программистами еще до того как вы присоединились к команде и по-прежнему работает должным образом. Бывает, всплывают баги, которые приходится исправлять, но это вполне ожидаемое явление. А больше ничего плохого сказать о программе вроде бы и нельзя. По крайней мере, так кажется со стороны. Эта программа решает проблемы пользователей и работает в соответствии с ожиданиями.
На как насчет кода? Как насчет программистов? Что они думают о своей программе?
Как один из разработчиков, участвовавших в создании этого ПО, вы видите все совершенно иначе. Для начала, вы считаете, что кодовая база слишком велика. Вы уверены, что можно было бы создать точно такой же функционал, но при этом обойтись куда меньшим количеством кода.
Вам кажется, что кодовая база также слишком сложна. Вы знаете, что этот код можно было бы написать получше, более простым и хорошо структурированным образом.
Добавление нового функционала и вообще реализация чего-то нового протекает сложно и болезненно, потому что вам приходится учитывать то, как связаны между собой разные части кода. Из-за этого внесение изменений становится небыстрым процессом.
Как насчет дебаггинга? На обнаружение и исправление багов также уходит слишком много времени.
Но если не принимать во внимание плохой дизайн и некрасивость кода, программа работает хорошо и пользователи довольны. И вы оказываетесь на раздорожье, где вам приходится выбирать один из возможных путей. С одной стороны, можно следовать старому инженерному правилу «Работает — не трожь!», а с другой стороны не помешало бы провести рефакторинг, чтобы сделать код более понятным и читаемым, и тем самым облегчить себе дальнейшую работу над этой кодовой базой. Какой путь выбрать?
Два типа мышления у программистов
Прежде чем дать ответ относительно выбора направления, я хотел бы немного остановиться на типах мышления программистов относительно исправления плохого, но рабочего кода.
Одни программисты четко следуют старому правилу «Не сломано — не исправляй». Для них стиль кода не имеет большого значения. Это программисты, для которых важен результат.
Код может быть сложным и плохо структурированным, он может не соответствовать важным принципам программирования, но этих программистов не волнует то, насколько хорошо написан код. Их беспокоит только то, что этот код делает.
Поэтому для таких программистов исправление плохо написанного кода это напрасная потеря времени. Код работает. Зачем же его трогать?! Кроме того, существует большой риск того, что в процессе исправления кода будут внесены новые баги.
Программисты с таким типом мышления просто не будут трогать старый код без острой необходимости.
Есть и другие программисты, с другим типом мышления. Они воспринимают код как произведение искусства, и им просто некомфортно, если код не соответствует их стандартам (хотя и работает). Читая плохо написанный код, они будут чувствовать отвращение. Они будут пытаться исправить каждый кусочек кода в проекте, потому что для них важен стиль написания кода, да и вообще, в коде все должно быть прекрасно.
Эти программисты чересчур одержимы стилем. Даже если их коллеги пишут хорошо структурированный код, они будут предпринимать попытки изменить его, чтобы подогнать под свой стиль написания.
В общем, программисты такого склада уж точно не будут следовать правилу насчет того, что не надо чинить несломанное. Они будут исправлять все. И то, окажется ли в конечном итоге этот код рабочим, имеет для них второстепенное значение.
Какое решение этой проблемы будет наилучшим?
Возьмите те части кода, над которыми вы работаете активнее всего, и исправьте их, сделав более читаемыми и понятными. Не трогайте другие части, если они работают должным образом и не имеют багов.
Почему важно уделить внимание основным частям? Именно с ними вы работаете чаще всего. Именно их чаще всего приходится читать. Именно в них чаще всего приходится вносить изменения. И если потребуется добавить в программу новый функционал, он напрямую будет связан с ядром кодовой базы. Также именно в основных частях содержится наибольшее количество багов, которые придется находить и исправлять. Помните о принципе Парето: «20% кода содержат 80% ошибок. Найдите их и исправьте!»
Как насчет остальных частей кодовой базы?
С ними вы работаете редко. В них нет багов. Написаны они давно — месяцы, а то и годы назад — и работают, как должно. Просто они не выглядят красиво. Но даже с учетом того, что их можно было бы переписать, чтобы сделать проще, читабельнее и понятнее, делать это вовсе не обязательно. Кто знает, когда вам вообще придется в следующий раз глянуть на этот код или что-то менять в нем? Так что эти части вполне могут остаться в своем исходном состоянии. Вы можете потратить свое время более эффективно — работая над вещами поважнее.
Почему важно исправлять основные части кода, даже если они работают должным образом?
Если вы хотите, чтобы ваша программа служила пользователям верой и правдой долгие годы, ваш продукт должен оставаться поддерживаемым. А поддерживаемость предполагает, что внесение изменений не должно быть трудным делом. Отладка и исправление багов не должны занимать слишком много времени. Добавлять новый функционал должно быть просто. При таком положении дел будут довольны как программисты, так и пользователи программы.
Мартин Фаулер в своей книге «Рефакторинг. Улучшение проекта существующего кода» говорит: «Когда вы представляете себе программистов, вы думаете, что они проводят большую часть своего времени за написанием кода. Но на самом деле то лишь малая часть их работы. Большую часть своего времени программисты проводят за чтением и отладкой кода. Каждый программист может рассказать свою историю о баге, который пришлось искать целый день. Исправление бага обычно происходит довольно быстро, но поиски это настоящий кошмар».
Чем лучше написан ваш код, тем проще в нем разобраться. А чем проще в нем разобраться, тем легче ваша работа.
Вот почему важно не следовать старому правилу инженеров в отношении основных частей вашей кодовой базы.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]
