Если приходится писать тесты для махрового легаси, которое писали до вас, то советую посмотреть на книжку Физерса «Эффективная работа с легаси»: bespoyasov.ru/blog/working-e…
Он предлагает искать швы — места, в которых можно относительно безопасно «распилить» комбайн на части.
Покрыть швы тестами, а уже потом начинать рефакторинг. Обычно шов — это место, где мы можем заменить одно поведение другим: месте соединения модулей.
В хорошо написанном коде такие места выделены явно, потому что модули слабо зацеплены.
Представьте, где именно вы бы разделили систему на несколько частей (по смыслу, по поведению, по зависимостям) — там и будет шов.
В книжке много техник, как работать с кодом, когда вы уже определились со швом.
Типа, как заменить зависимость:
- одну зависимость за раз;
- определить, какую зависимость хотим поменять;
- покрыть шов тестами;
- вынести текущий код в отдельный класс;
- заменить класс на другой.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Давайте под конец рабочей недели поговорим о ведении технического (и не только) блога!
- Зачем вообще вести, как начать писать;
- Насколько глубоко уходить в тех. детали в постах;
- Свой хостинг или блогоплатформа;
- Русский или английский язык.
Кидайте ссылки на свои блоги!
Расскажите, ведёте ли вы свой блог?
как начинали?
что подтолкнуло?
что для вас самое сложное?
какие плюшки вы от блога получаете?
Дублирование кода _на ранних этапах_ может показать, как всё на самом деле работает, и какие паттерны мы ещё не увидели.
Удаление дублирования — это прогнозирование будущего. Чем больше исходных данных удастся собрать, тем точнее будет прогноз.
Чтобы не потерять места с копипастой, помечаю их коммент-флагом `DUPLICATE`.
После самого флага пишу, какую функциональность он дублирует. Это даёт флагу осмысленное и уникальное имя, по которому потом проще искать места для рефакторинга.