Закоулки мозга

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

  1. Выбрать точку фокуса (choose where to look)
  2. Придумать изменение (have an insight)
  3. Записать изменение в коде (write it down)
  4. Изменение сделало код хуже?
    • Да -> откатить изменения, вернуться к шагу 2
    • Нет -> закоммитить изменения, вернуться к шагу 1

Очень похоже на технику Mikado, подразумевает короткие петли обратной связи, однозначно требует наличия юнит-тестов, если не используются “атомарные рефакторинги”.


@tech-debt:Технический долг - это баги и неопределенность

Суть в том, что тех.долг редко оказывает значительное влияние на стоимость разработки. К тому же, затраты, вызванные тех.долгом, сложно определить. Баги, неопределенность и риски более опасны для проекта, нежели рост затрат. Главное следствие технического долга - дефекты, а не рост затрат


@safe-refactorings:Совместимость по багам

От багов в продукте часто зависят пользователи.

Пользователем может быть соседняя часть системы.

Поэтому рефакторить не покрытый тестами код нужно так, чтобы сохранить в нем все существующие баги и все существующее поведение. Для этого есть “атомарный рефакторинг” (см. Тагир Валеев “Атомарный рефакторинг в IntelliJ IDEA: прогибаем IDE под себя”:


Нечитабельный код опасен

Неясность намерений программиста и сокрытие информации о побочных эффектах приводят к возникновению багов.


Нетестируемый код опасен

Нетестируемый код - это код, поведение которого мы не можем изолировать от других частей системы, это источник багов.


Методы работы изменяют мышление