Эволюционная архитектура. Поддержка непрерывных изменений

Реальная мера успеха — это число экспериментов, которые можно провести в течение 24 часов.

— Томас Алва Эдисон (Thomas Alva Edison)

три попытки — и Вы уже выполняете рефакторинг

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

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

КОМАНДЫ Amazon «На Две пиццы»

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

Организуйте команды вокруг бизнес-возможностей, а не функцио­нальных обязанностей.

Каждая компания — теперь софтверная компания.

— Журнал Forbes, 30 ноября 2011 г.

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

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

Проект IBM Сан-Франциско

В конце 1990-х годов IBM выступила с амбициозным планом написать программу, которая решит все задачи бизнеса, и писать больше ничего не придется. Команда разработчиков приступила к проектированию набора повторно используемых бизнес-компонентов, написанных на языке того поколения Java, которое могло инкапсулировать всю бизнес-функциональность в широкие категории: книгу учета бухгалтерии, товарные запасы, продажи и т.п. В какой-то момент компания IBM заявила, что этот проект представляет собой крупнейший Java-проект на Земле (http://www.drdobbs.com/ibms-san-francisco-project/184415597). Проект предоставил первые несколько модулей ядра, и разработчики начали использовать фреймворк, который привел к его кончине. Многие функции оказались ненужными, а много важных функций при этом отсутствовали.

Проект Сан-Франциско демонстрирует завышенную самооценку разработчиков, которые пытались следовать своим инстинктам для категоризации и классификации всего на свете. Некоторые беспорядочные события реального мира нарушают изящные решения, включая все бизнес-процессы!

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

Обновлять зависимости фреймворка следует активно; обновлять библиотеки следует пассивно.