Мой коллега сказал мне немного назад, что красный-зеленый вместо красного-зеленого-рефактор становится проблемой: многие коммиты были сделаны именно тогда, когда была достигнута зеленая полоса. Причиной такого поведения был страх перепроектировать систему и код на завтра, а не на сегодняшний день: XP подчеркивает концепцию простого решения сегодняшней проблемы вместо неправильного предвидения будущих проблем и разработки для неправильных изменений.
В то же время код, дизайн которого не улучшается после того, как зеленая полоса склонна к тому, чтобы не быть чистым и устойчивым, если вы не очень увлечены процессом проектирования * во время * красной фазы (с четким определением Mocks и Stubs) ,
Эти четыре знаменитых правила заставят вас писать чистый код во время TDD, а не останавливаться на зеленой полосе .
Список
Вы закончили с рефактором 3-й фазы, когда код (который, кстати, является дизайном):
- Проходит все тесты.
- Выразите каждую идею, которую нам нужно выразить.
- Не содержит дубликатов.
- Минимизировано количество классов, методов и других движущихся частей.
Давайте рассмотрим, что мы разрабатываем (например, один класс), и проанализируем правила и то, как они применяются к нашему типичному процессу.
Я думаю, что здесь есть порядок важности , где компромисс для улучшения i над i +1 должен быть предпочтительным. Порядок пунктов 2 и 3 варьируется в зависимости от источников, но если бы мне пришлось выбирать между ними, я бы предпочел выразительность, а не дублирование.
1. Проходит все тесты, это самое важное правило. Если вы вернетесь к красной полосе, ваш рефакторинг недействителен, и вы должны вернуться в зеленое состояние, чтобы начать снова. Рефакторинг в красном опасен и теоретически (мы все люди), вы не должны оставаться красным в течение более нескольких минут.
Это правило также означает, что если вы пишете код, не предназначенный для выполнения теста (единичного или сквозного, функционального или любого другого вида, это не имеет значения), вы даже не удовлетворяете первому из 4 условий.
Это должен быть ваш лучший друг:
2. Выразите каждую идею, которую нам нужно выразить. Учитывая, что ваш код проходит все тесты, вы можете явным образом «показать» свой дизайн. Например, конкретные классы или делегирование методов, которые не изменяют реализацию, приемлемы для связи, даже если технически они представляют собой дублирование и нарушают 3 (что менее важно в данном случае imho).
Например, эти два класса:
class AsideBox extends DivTag {}
class ArticleText extends DivTag {}
важны для меня на семантическом уровне, даже если они не изменяют какую-либо деталь DivTag. Они также могут использоваться для подсказок типа в динамических языках или более точных проверок во время компиляции в статически типизированных.
3. Учитывая, что код проходит тесты и надежно выражает ваш дизайн, вы можете полностью извлечь методы и классы, чтобы исключить дублирование . Это правило широко распространено и обсуждается, я думаю, из-за его простоты применения; в большинстве случаев легко увидеть дублирование: вместо этого все выражают все концепции, возникшие в процессе разработки (2).
Существует компромисс между извлечением дублированного кода и его ясностью. Я помню, как извлекал абстрактный класс, подобный этому, некоторое время назад:
abstract class ChangeOperation {
protected ChangeRegistry registry;
public function ChangeOperation(ChangeRegistry registry) {
this.registry = registry;
}
}
устранить дублированный конструктор. Эта операция находится на грани моего списка рефакторингов: извлечение еще кода просто разбивает объекты на абстрактные понятия вместо удобочитаемой объектной модели. Если бы я не смог быстро осмысленно назвать этот абстрактный класс, я бы просто избежал его извлечения.
4. Простая конструкция — это извлечь из вашего кода все, что вы можете, не нарушая 1, 2 и 3. Панель должна оставаться зеленой, вы не должны страдать от удаления полезных понятий, которые делают код более читабельным и понятным, и вы не должны этого делать. ввести в процесс дублирование (например, снова включить класс или метод).
Это правило способствует эволюционному дизайну, а не дизайну на завтра. Вы можете написать код, предвидя изменения, и усложнить обработку будущих изменений (Strtegy / Bridge). Но так как невозможно последовательно предсказать ось изменения, вы в конечном итоге вводите сложность для того, чтобы справиться с изменением, которого не происходит, в то время как рефакторинг необходим в любом случае для непредвиденных изменений.
Больше ссылок
Дизайн — это способность, которая приобретается годами, но я надеюсь пролить немного света на эти принципы, которые сами по себе могут показаться просто идеалом, состоящим из модных словечек. Как всегда, это великаны, на плечах которых мы стоим.
Объяснение экстремального программирования, 2-е издание Кента Бека