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