Refactoring

Парадокс рефакторинга, о котором никто не говорит Вы тысячу раз слышали: «Пишите юнит-тесты! Они — ваша страховка! Они дают вам уверенность в рефакторинге!» И знаете что? Это абсолютная правда. Если только это не так. В карьере каждого разработчика наступает момент, когда они обнаруживают, что их набор тестов — то самое, что должно было их освободить, — стало бетонными ботинками. Вам нужно рефакторить класс, извлечь метод, перестроить структуру модуля, и внезапно половина ваших тестов начинает ломаться....

Позвольте мне быть откровенным: я присутствовал на множестве совещаний, где инженеры с энтузиазмом объясняли, почему нам нужно провести рефакторинг модуля аутентификации, но при этом видел, как у бизнес-стейкхолдеров стекленеют глаза, словно они наблюдают, как сохнет краска в плохо освещённом складе. Ответ всегда один и тот же: «А нельзя ли сначала просто выпустить функцию?» Болезненная правда заключается в том, что большинство из нас подходят к этому разговору, пытаясь убедить кого-то, что брюссельская капуста вкусная....

Аргументы против масштабной переработки Представьте себе картину, которую вы, вероятно, уже видели: два часа ночи вторника, ваша производственная система не работает, и где-то в канале Slack кто-то печатает: «…а может, просто переписать всё с нуля?». Это момент, когда многие инженерные команды принимают решение, которое будет преследовать их годами. Масштабная переработка. Звучит привлекательно — чистый лист, новый стек технологий, уроки, извлечённые из прошлого, применяются с первого дня. Но почти всегда это оборачивается катастрофой....

Одержимость шаблонами Признаюсь честно: я был в такой ситуации. Вы знаете это чувство, когда обнаруживаете новый блестящий шаблон проектирования, и вдруг всё в вашем коде выглядит как гвоздь, ожидающий именно этого молотка? Добро пожаловать в одержимость шаблонами — болезнь, поражающую кодовые базы по всему миру на протяжении большей части трёх десятилетий. Вот неудобная правда, которую никто не хочет признавать на совещаниях по архитектуре: шаблоны проектирования — это не священное писание. Это решения конкретных проблем, рождённые из реальных ограничений и с трудом обретённого опыта....

Представьте: вы торопитесь закончить работу до срока, который приближается быстрее, чем белка, напившаяся кофе. Ваша команда могла бы создать «идеальное» решение примерно за три недели. Или вы можете запустить рабочую версию завтра, стратегически сократив некоторые этапы. Добро пожаловать в искусство намеренного технического долга — где умные shortcuts становятся суперспособностями, а не грехами. В отличие от случайных ошибок в коде, возникающих после ночных сессий кодирования (#Виноваты), намеренный технический долг — это осознанный компромисс — рассчитанный риск, который даёт вам пространство для манёвра сегодня, планируя уборку на завтра....