Перевод статьи «Core Frameworks Don’t Work (most of the time)» от Rudy Lacovara, в которой он критикует практику, когда компании создают собственные универсальные платформы для разработки ПО, на основе которых реализуют несколько совершенно не связанных проектов. На картинке изображен Борг из Стар Трека, это раса киборгов, которая ассимилирует все встречающиеся организмы в единый супер-организм.

Я консультирую серьезные софтверные компании, которые поддерживают большие информационные системы на базе .net с миллионами транзакций в день. Как правило, мой контракт с ними длится от 1 до 2 лет. За это время я успеваю копнуть достаточно глубоко, и при этом я успел поработать с множеством различных компаний. Это позволяет мне делать интересные наблюдения и выводы об их процессах разработки ПО. Я своего рода Николай Дроздов, который наблюдает естественное поведение передовых софтверных компаний в их естественных условиях.

Часто я вижу одну интересную практику, которая называется «универсальная платформа» («the core framework»). Некоторые компании называют это «наша платформа», «наш фреймворк», другие называют это просто «ядром». Но независимо от того как Вы это назовете, практика подобной универсальный платформы, как правило (но не всегда), является злом, которое негативно отражается на конечной продуктивности вашей компании.

Суть явления

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

Ядро приложения обычно представляет собой слой бизнес-логики, который используется различными модулями на слое приложения в одном проекте. Например, ядро приложения SquareHire используется в веб-сайте, веб-приложении, веб-админке, обработчике и API. Все эти различные модули работают с некоторыми общими данными и функционалом бэк-энда. Все вместе они составляют единый проект SquareHire, поэтому выделение для них общего ядра приложения это правильная практика.

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

Как это происходит?

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

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

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

В этот момент кому-то в голову приходит гениальная идея: «Я знаю, как мы можем делать проекты на порядок эффективнее, и все наши программы будут работать гораздо лучше! Нам достаточно разработать одну идеальную стандартную архитектуру, и чтобы все в компании перешли на ее основу. Мы создадим набор базовых библиотек, и каждый новый проект будем делать на них».

Идея универсальной платформы

На первый взгляд, идея универсальной платформы имеет смысл. Можно найти несколько сильных аргументов в пользу разработки подобной стандартной общей платформы. Вот некоторые из них:

1. Разработка с нуля будет быстрее и легче
Новые проекты будет значительно легче довести до рабочего состояния. Для них не надо будет писать кучу стандартного кода, все, что нужно они получат из платформы.

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

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

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

Универсальная платформа на практике

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

1. Разработка с нуля будет быстрее и легче
Платформа действительно может ускорить реализацию начальной фазы нового проекта, но это ненадолго. Довольно быстро разработчики обнаруживают, что она наряду с преимуществами накладывает и свои ограничения. Вскоре разработчики нового проекта начинают планировать встречи с архитектором и командой платформы для того чтобы понять, как можно ее модифицировать, чтобы приспособить к нуждам своего проекта. Вы понимаете, что происходит? Платформа не только не подходит для нового проекта, новый проект начинает влиять на платформу. И это происходит с каждым проектом, который ее использует. В итоге мы получаем сильную зависимость между всеми проектами. Теперь представьте, что в один прекрасный день Вы в своем проекте обновляете версию платформы до последней и обнаруживаете, что весь проект сломан, потому что другая команда решила, что есть лучший способ управления транзакциями, или они поменяли DI контейнер, или что-то еще. Представили?

2. Формирование команд упростится
Это действительно работает в определенной степени. Различные проекты компании имеют схожую структуру, поэтому разработчикам легче переходить между ними. К сожалению, есть и обратная сторона монеты.

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

Также я заметил, что наличие платформы усложняет для компании процесс найма новых разработчиков. Как правило, при развитии платформы резко растет ее сложность. Менеджеры мне часто жаловались, как трудно найти разработчиков, и даже после нахождения нужно 5 или 6 месяцев, чтобы от них появилась реальная отдача, и все потому что архитектура проекта очень сложна. Должна ли платформа быть такой сложной? Нет, но по некоторым причинам так всегда и происходит… что ведет нас к аргументу номер 3.

3. Нас направят самые сильные и опытные профессионалы
Платформа всегда создается лучшими разработчиками в компании. И это очень хорошо, так ведь? Нет. Здесь две большие проблемы.

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

Вторая проблема – это интересный феномен, который я назвал «Синдром крутого разработчика» («Smart Guy Disease»). Я встречался с ним много раз в разных компаниях. Заключается он в том, что самые фатальные ошибки, которые наносят наибольший ущерб компании, почему-то всегда делаются самыми лучшими ее разработчиками, а не посредственными. Если Вам это интересно, здесь я написал об этом целую статью.

Заключение

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

Могу предложить такую альтернативу: создайте универсальную базу исходного кода. Но вместо того, чтобы наследовать и использовать ее в каждом новом проекте (что приведет к межпроектной зависимости), просто каждый раз делайте ее форк. В таком случае у Вас будет надежная стартовая точка, но при этом Вы свободно вносите изменения, не беспокоясь о том, как они отразятся на других проектах компании.

habrahabr.ru