Метафоры как средство моделирования очень важны.
Метафора строительства неактуальна для разработки ПО
Процесс разработки ПО - это совокупность двух взаимодействующих, но тем не менее, раздельных сущностей: кода и команды. Подтверждение тому - закон Конвея Закон Конвея. Связь этих сущностей говорит нам о том, что проблемы в коде связаны с проблемами в команде и наоборот. Поэтому у нас есть два варианта их решения: со стороны кода и со стороны команды.
Новая метафора
Здание - это инфраструктура, которую мы используем при разработке приложений. Фундамент - это ОС, технические этажи и парковки - язык программирования, каркас здания - выбранные фреймворки. А мы разрабатываем приложения внутри этих структур, мы теперь не архитекторы, а дизайнеры интерьеров.
Каждое здание оптимизировано для своих целей (см. “Источник” Айн Рэнд). Приложения могут быть размещены в любом здании, но где-то это получится лучше, а где-то - хуже, так как код будет определенным образом сформирован окружающим пространством.
Если добавить к этому то, что проекты сейчас никогда не считаются законченными (как раньше, при “водопадной” модели разработки), то приходишь к мысли, что код - это не то, что мы строим, а то, где мы живем.
Новая цель
Место, где мы живем, нужно сделать пригодным для жилья - комфортным и удобным. В случае с кодом, это означает сделать его понятным, поддерживаемым, расширяемым для всей команды, которая в нем “проживает”.
Команда, вероятно, влияет на благополучие проекта сильнее, чем собственно код или выбранный фреймворк.
Спасение через изменение привычек
Дома превращаются в помойку из-за череды мелких неверных решений, типа не помытой после ужина посуды. Причем, даже если в доме провести генеральную уборку, со временем он вернется в прежнее захламленное состояние, потому что владельцы будут все так же принимать мелкие неверные решения. С кодом - та же история.
Оказывается, более эффективным способом является постепенная продолжительная работа не с содержимым дома, а с самими людьми. Цель - изменить их привычки. В случае с кодом - это командные привычки и нормы.
не каждый обязан участвовать в перестановке мебели, но каждый должен мыть за собой посуду.
Первичную “генеральную уборку” может стимулировать страх (“кнут”?), а мотивацию для долгосрочных позитивных сдвигов дает только удовольствие (“пряник”). Для успешного изменения качества кода нужны оба подхода. См. 18 минут, совет 32.
Конкретные приемы
- Не навреди. Код не должен становиться хуже. Даже если у нас мало времени.
- Последовательные улучшения. Код должен становиться хоть чуточку лучше каждый раз, когда кто-то с ним работает. (Правило скаутов: Оставляй лагерь чище, чем он был до твоего прихода)
- Уборка - часть работы. Научитесь встраивать простые правила в ежедневную работу. Не создавайте отдельных задач на рефакторинг и не ждите следующего спринта, чтобы начать работать над ними.
- Поддерживайте связь. Общайтесь с командой по поводу того, что вы делаете.
- Не спрашивайте разрешения, ведь рефакторинг - это часть вашей работы. Но при этом будьте открыты к обсуждению ваших решений.
- Не уклоняйтесь от ответственности и учитесь на ошибках.
- Спрашивайте советов, но не всегда следуйте им.
- Делайте все вместе, потому что вам вместе здесь жить.
Заключение
Самая важная часть разработки ПО — не код и не люди. Самая важная часть — система. Чем больше мы думаем о разработке, как о взаимосвязанной системе кода и людей, тем ближе мы к революции, и к проектам, в которых хочется работать.
Вы тоже можете к этому прийти. Не важно насколько плохо обстоят дела сейчас — вы все сможете. Если вы построите доверительные отношения и укрепите связи внутри команды, если каждый будет относиться с уважением к коду, в котором он работает, если вы примете реальность и откажетесь от иллюзий переписать все заново и пообещаете друг другу выполнять правила, то у вас все получится.