Belshee A. Master Legacy Code Incrementally // 2020.
https://www.youtube.com/watch?v=9YxQzjtPdtw
@ratchet-and-safe:Храповик и безопасные изменения
Принцип действия храповика (движение только вперед; невозможность ухудшения положения) и работа только с помощью безопасных изменений - две движущие силы постоянного улучшения состояния кода.
@simple-enitity-and-names:Точные имена для простых сущностей
Точные имена намного проще подобрать для максимально простых сущностей, см. например, Single Responsibility Principle - принцип единой ответственности.
@makers-and-menders:Творцы и ремонтники
Творцы и ремонтники - два типа программистов
Творцы создают. Они пилят новые фичи, они обладают видением решения и т.п.
Ремонтники изучают и выращивают, они понимают, что делает код и что он должен делать, и превращают код в такой, который легко читать, понимать и изменять, но который при этом по-прежнему гарантированно делает именно то, что должен.
(см. 30:00)
@insight-loop:Цикл работы Insight Loop
- Выбрать точку фокуса (choose where to look)
- Придумать изменение (have an insight)
- Записать изменение в коде (write it down)
- Изменение сделало код хуже?
- Да -> откатить изменения, вернуться к шагу 2
- Нет -> закоммитить изменения, вернуться к шагу 1
Очень похоже на технику Mikado, подразумевает короткие петли обратной связи, однозначно требует наличия юнит-тестов, если не используются “атомарные рефакторинги”.
@tech-debt:Технический долг - это баги и неопределенность
Суть в том, что тех.долг редко оказывает значительное влияние на стоимость разработки. К тому же, затраты, вызванные тех.долгом, сложно определить. Баги, неопределенность и риски более опасны для проекта, нежели рост затрат. Главное следствие технического долга - дефекты, а не рост затрат
@safe-refactorings:Совместимость по багам
От багов в продукте часто зависят пользователи.
Пользователем может быть соседняя часть системы.
Поэтому рефакторить не покрытый тестами код нужно так, чтобы сохранить в нем все существующие баги и все существующее поведение. Для этого есть “атомарный рефакторинг” (см. Тагир Валеев “Атомарный рефакторинг в IntelliJ IDEA: прогибаем IDE под себя”:
Неясность намерений программиста и сокрытие информации о побочных эффектах приводят к возникновению багов.
Нетестируемый код - это код, поведение которого мы не можем изолировать от других частей системы, это источник багов.
Методы работы изменяют мышление