Чистый Agile. Основы гибкости - [45]

Большой рефакторинг

Иногда требования меняются так, что вы осознаете: дизайн и архитектура программы не совсем подходят. Тогда вы решаете внести значительные изменения в структуру программы. Такие изменения вносят в цикле «красный/зеленый/рефакторинг». Мы не создаем программы специально для того, чтобы вносить изменения в структуру. Мы не выделяем времени в графике работ на такой глубокий рефакторинг кода. Маленькими порциями мы переносим код, продолжая добавлять новые функции за время обычного цикла Agile.

Такое изменение в структуру программы можно вносить несколько дней, недель или даже месяцев. Все это время программа проходит все необходимые тесты и готова к развертыванию, даже если изменение структуры не полностью завершено.

Простота проектирования

Метод «простота проектирования» — одна из целей рефакторинга. Простота проектирования — метод, предполагающий написание только необходимого кода, чтобы сохранять простоту структуры, его небольшой размер и наибольшую выразительность.

Правила простого проектирования Кента Бека.

1. Пройти все тесты.

2. Проявить намерение.

3. Удалить дубликаты.

4. Сократить количество элементов.

Номера пунктов означают порядок действий, в котором эти правила выполняются, и их приоритет.

Пункт 1 говорит сам за себя. Код должен пройти все тесты. Он должен работать.

В пункте 2 указано, что после того как код заработал, ему нужно придать выразительность. Он должен явно отражать намерения программиста. Код нужно писать так, чтобы он легко читался и содержал достаточно сведений. Как раз сейчас мы проводим косметический рефакторинг кода, в течение которого вносим много простых изменений. Нужно также разделить большие функции на мелкие, дав им более простые и понятные названия.

В пункте 3 говорится, что после того как код получился в высшей мере описательным и выразительным, мы старательно выискиваем и удаляем все дубликаты. Не нужно, чтобы в коде повторялось одно и то же. Во время такой деятельности проводить рефакторинг, как правило, сложнее. Иногда удалить дубликаты так же просто, как перенести дублирующийся код в функцию и вызвать его из разных мест. В других случаях требуются решения интереснее, например паттерны проектирования[54]: метод шаблонов, стратегия, декоратор или посетитель.

В пункте 4 говорится о том, что как только мы удалили все дубликаты, нужно стремиться уменьшить количество структурных элементов, например классов, функций, переменных и так далее.

Цель метода «простота проектирования» — поддерживать наиболее возможную легковесность кода.

Легковесность

При проектировании программа может получиться как достаточно простой, так и необычайно сложной. Чем сложнее структура, тем больше умственная нагрузка на программиста. Эта умственная нагрузка — вес структуры программы. Чем больше вес программы, тем больше времени и усилий будет затрачено программистами на изучение и управление этой программой.

Таким же образом сложность требований также варьируется от небольших до огромных. Чем сложнее требования, тем больше времени и сил понадобится, чтобы изучить эту программу и управлять ею.

Однако обе причины не являются дополняющими. Сложные требования можно упростить за счет усложнения структуры программы. Часто предпочтительнее найти компромисс. Программу можно упростить, подобрав подходящую конструкцию под заданный набор функций.

Уравновешивание сложности конструкций и функций является целью «простоты проектирования». Применяя этот метод, программисты постоянно перепроектируют структуру кода, чтобы сохранялось равновесие между требованиями и достижением наиболее высокой производительности.

Парное программирование

Метод парного программирования за годы своего существования оброс противоречиями и кривотолками. Многие отрицательно воспринимают мысль о том, что два (и больше) человека могут плодотворно работать над одной и той же задачей.

Во-первых, работа в паре не обязательна. Никого нельзя к ней принуждать. Во-вторых, работа в паре не обязательно постоянна. Существует много веских причин, почему иногда лучше писать код в одиночестве. Желательно, чтобы доля программистов, работающих в паре, в команде была 50 % или около того. Но это не так важно. Она может быть лишь 30 %, а может и все 80 %. Право выбора принадлежит членам команды.

Что такое парное программирование?

Парное программирование — это совместная работа двух программистов над одной задачей. Напарники могут работать на одной машине, с одним монитором, клавиатурой и мышью. Или они могут работать на двух машинах по сети, пока могут видеть один и тот же код и обращаться с ним. Последнее прекрасно можно осуществить с помощью систем доступа к рабочему столу. Такое ПО позволяет напарникам находиться далеко друг от друга, если у них хорошая пропускная способность и голосовая связь.

Программисты, работающие в паре, выполняют разную работу. Один будто водитель, а другой — штурман. У водителя в руках инструменты — клавиатура и мышь. Штурман же внимательно всматривается в монитор и дает советы. Другой вариант: один программист пишет тест, а второй добивается его прохождения, после чего пишет ответный тест первому программисту. Иногда этот метод называют «пинг-понг».