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