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

Источник

Метафоры как средство моделирования очень важны.

Метафора строительства неактуальна для разработки ПО


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

Новая метафора

Здание - это инфраструктура, которую мы используем при разработке приложений. Фундамент - это ОС, технические этажи и парковки - язык программирования, каркас здания - выбранные фреймворки. А мы разрабатываем приложения внутри этих структур, мы теперь не архитекторы, а дизайнеры интерьеров.

Каждое здание оптимизировано для своих целей (см. “Источник” Айн Рэнд). Приложения могут быть размещены в любом здании, но где-то это получится лучше, а где-то - хуже, так как код будет определенным образом сформирован окружающим пространством.

Если добавить к этому то, что проекты сейчас никогда не считаются законченными (как раньше, при “водопадной” модели разработки), то приходишь к мысли, что код - это не то, что мы строим, а то, где мы живем.

Новая цель

Место, где мы живем, нужно сделать пригодным для жилья - комфортным и удобным. В случае с кодом, это означает сделать его понятным, поддерживаемым, расширяемым для всей команды, которая в нем “проживает”.

Команда, вероятно, влияет на благополучие проекта сильнее, чем собственно код или выбранный фреймворк.

Спасение через изменение привычек

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

Оказывается, более эффективным способом является постепенная продолжительная работа не с содержимым дома, а с самими людьми. Цель - изменить их привычки. В случае с кодом - это командные привычки и нормы.

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

Первичную “генеральную уборку” может стимулировать страх (“кнут”?), а мотивацию для долгосрочных позитивных сдвигов дает только удовольствие (“пряник”). Для успешного изменения качества кода нужны оба подхода. См. 18 минут, совет 32.

Конкретные приемы

  1. Не навреди. Код не должен становиться хуже. Даже если у нас мало времени.
  2. Последовательные улучшения. Код должен становиться хоть чуточку лучше каждый раз, когда кто-то с ним работает. (Правило скаутов: Оставляй лагерь чище, чем он был до твоего прихода)
  3. Уборка - часть работы. Научитесь встраивать простые правила в ежедневную работу. Не создавайте отдельных задач на рефакторинг и не ждите следующего спринта, чтобы начать работать над ними.
  4. Поддерживайте связь. Общайтесь с командой по поводу того, что вы делаете.
    1. Не спрашивайте разрешения, ведь рефакторинг - это часть вашей работы. Но при этом будьте открыты к обсуждению ваших решений.
    2. Не уклоняйтесь от ответственности и учитесь на ошибках.
    3. Спрашивайте советов, но не всегда следуйте им.
    4. Делайте все вместе, потому что вам вместе здесь жить.

Заключение

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

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

Связи и ссылки: