Осторожно: общий код
Уди Дахан
Мой первый проект в компании. Я только что защитил диплом, мне не терпится проявить себя, так что я допоздна засиживаюсь на работе и тщательно изучаю существующий код. Работая над своей первой задачей, я применяю все, чему меня учили: комментарии, журналы событий, выделение общего кода в библиотеки (где это возможно), все дела. Мне кажется, что я полностью готов к рецензированию кода, но коллеги словно окатывают меня холодным душем: я получаю за повторное использование кода!
Как так? Во время моей учебы в колледже повторное использование кода превозносилось в числе лучших практик разработки программ. Все прочитанные мною статьи и учебники, наставлявшие меня опытные профессиональные программисты — неужели все они ошибались?
Оказывается, я упустил из виду нечто очень важное.
Контекст.
Тот факт, что две напрямую не связанные части системы пользуются одной и той же логикой, означает меньше, чем мне казалось. До того как я поместил общий код в одну библиотеку, эти части работали независимо одна от другой. Они могли независимо развиваться. Логика каждой из них могла измениться в соответствии с меняющимися требованиями бизнес-среды. Те четыре строчки похожего кода возникли случайно — временная аномалия, совпадение. Ну, то есть это было совпадением, пока за дело не взялся я.
Созданные мною библиотеки общего кода связали шнурки ботинок в один клубок. Любое движение в первой предметной области требовало синхронизации со второй предметной областью. Пока функции были независимы, стоимость их сопровождения была пренебрежимо мала, но как только появилась общая библиотека, объемы необходимого тестирования выросли на порядок.
Сократив абсолютное число строк кода системы, я вместе с тем увеличил количество зависимостей. Контекст этих зависимостей крайне важен: находись они в одном месте, общий код можно было бы оправдать и извлечь из него пользу. Но если не держать эти зависимости под контролем, они запустят свои щупальца в более важные вопросы функционирования системы, даже если сам по себе код с виду безупречен.
Коварство таких ошибок — в правильности основополагающих идей. Подобные приемы применять в должном контексте полезно, а вот в неверном контексте от них больше убытков, чем пользы. Теперь, если я работаю с кодом существующего проекта и не знаю, где могут использоваться различные его части, я гораздо осторожнее подхожу к совместному использованию кода.
Осторожнее с общим кодом. Изучите контекст. И лишь затем действуйте.
Правило бойскаута
Роберт Мартин, известный также как «Дядюшка Боб»
У бойскаутов есть правило: «Оставь после себя лагерь чище, чем он был, когда ты пришел». Если на земле валяется мусор, ты убираешь его, даже если намусорили другие. Ты намеренно улучшаешь условия существования для следующей группы, которая придет в лагерь. (А исходно это правило, установленное основателем скаутского движения Робертом Стивенсоном Смитом Бейден-Пауэллом, звучало так: «Постарайся, чтобы этот мир стал лучше, чем до того, как ты в него пришел».)
Представьте, что мы следуем похожему правилу для нашего кода: «Всегда сохраняй модуль в репозиторий в лучшем состоянии, чем он был, когда ты его оттуда загрузил». Кто бы ни написал этот модуль изначально, что если потратить хоть немного сил, чтобы улучшить его? К чему это может привести?
Думаю, следуй мы все этому простому правилу, нам больше не пришлось бы видеть неумолимую деградацию наших программных систем. Напротив, они становились бы все лучше по мере своего развития. На смену отдельным людям, беспокоящимся лишь о собственных фрагментах работы, пришли бы целые команды, заботящиеся о системах в целом.
Мне кажется, такое правило не слишком сложно в исполнении. Необязательно доводить до совершенства каждый модуль, который вы возвращаете в репозиторий. Просто сделайте его чуть лучше, чем он был, когда попал к вам в руки. Естественно, это означает, что, расширяя модули собственным кодом, вы создаете чистый код. Кроме того, нужно навести порядок хотя бы еще в одном месте, прежде чем сохранять модуль. Достаточно лишь дать какой-то переменной более удачное имя или разбить длинную функцию на две более коротких. Можно устранить циклическую зависимость или добавить интерфейс, устраняющий зависимость между политикой и реализацией.
Честно говоря, мне кажется, что это обычные правила приличия — как мыть руки после туалета или выбрасывать мусор в мусорное ведро, а не на пол. Скажем прямо, оставлять беспорядок в коде должно быть столь же социально неприемлемо, как сорить на улице. Такого попросту не следует делать.