[3/5] Чистый дизайн (Tidy First?) (Рубрика Architecture)
Продолжая посты (1 и 2) о книге "Чистый дизайн" расскажу про вторую часть, в которой автор рассказывает о том, как управлять очисткой: когда начинать, когда заканчивать, а также как объединить ее с изменением поведения системы. Здесь автор дает следующие советы
- Очистка отдельно (separate tidying) - очистку надо проводить отдельно от изменений, что меняют поведение системы. Это можно легко организовать заворачивая все изменения по очистке в отдельный MR (merge request). Плюс надо думать над размером MR - он должен давать некоторую картину для понимания изменений, но, одновременно, не быть слишком большим для осмысления
- Цепочки (chaining) - когда вы начинаете очистку, то эти изменения начинают создавать изменения для дальнейшей очистки. Важно уметь планировать очистку на несколько шагов, а также знать, когда требуется остановиться. Подробнее про подходы к очистке можно прочитать во втором посте по книге
- Размер наборов операций (batch sizes) - здесь автор рассказывает как определиться с размером очистики. Он предлагает оценивать стоимость ревью изменений (что форсирует не делать маленькие MRs с очисткой) и проблемы с большими батчами по очистке: потенциальные коллизии, изменения в поведении и спекулятивные изменения. В итоге, нам надо найти оптимум:)
- Ритм (rhythm) - автор говорит о том, что в уборке нужна ритмичность - мы не можем разово убраться и забыть об очистке:) Нам надо делать это периодически, если мы хотим жить в чистом месте
- Распутывание (getting untangled) - иногда, при написании кода, изменяющего поведение, приходит идея провести очистку. Дальше опять дописать код, что меняет поведение, а потом еще почистить код. Автор предлагает не делать так, а если все таки у вас получилось такое запутанное изменение, то снести его и дальше сделать все сначала с новыми знаниями и пониманием, что надо поделить изменения поведения и очистку на отдельные MRs
- До, после, позже, никогда (first, after, later, never) - ответ на вопрос, а когда делать очистку. И это как обычно it depends ... И тут все зависит от экономических эффектов: если очистка сильно поможет нам с дальнейшим внесением изменений, то можно начать с нее. А если нам никогда-никогда не придется менять код (мы пишем разовый скрипт), то чистить ничего не требуется:) А вот варианты в промежутке уже посложнее и по ним автор дает следующие рекомендации:
- Проводите очистку после изменений, если -- Ожидание следующего удобного случая, чтобы провести ее сразу перед изменениями, обойдется дороже -- Без этого вы не чувствуете, что работа завершена
- Проводите очистку позже, если -- Очистка предполагает много работы, которая не возымеет немедленного эффекта -- Ее завершение окупится позже -- Ее можно проводить небольшими частями
#Architecture #Software #SystemDesign #Management #Leadership #SoftwareArchitecture