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

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

Речь про продвигаемый последние годы Agile. Да, у него есть свои преимущества — в первую очередь пресловутый time to market. Но не будем забывать, друзья, что у всех Agile фреймворков есть и обратная сторона — существенно более дорогая разработка по сравнению с Waterfall при масштабах компаний больше одной команды. Что характерно на обучениях об этом не говорят. Но если спросить напрямую, все agile коучи, внедрявшие гибкие методологии в компаниях, где я работаю, это подтвердили. Пусть и с кучей оговорок про «скорость» и «перспективность».

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

Есть время собирать камни, и есть время разбрасывать. Рано или поздно, специализируясь в какой то области, например в корпоративной архитектуре, человек начинает не только и не столько стремиться к получению знаний, необходимых для ориентирования в своей области, но и делиться накопленным обобщениями. Или опытом (сыном ошибок трудных). Не миновал этот этап и меня.

Начну с «исправления имен» как базы для совершенствования (меткое наблюдение конфуцианства) на примере того, как у нас переводится базовый принцип построения микросервисной архитектуры: «low coupling and high cohession». И как понимание терминологии помогает отличить профанов, изображающих с помощью птичьего языка некое знание, от действительно понимающих суть людей.

Прежде чем переходить к качественному переводу нужно понять контекст и суть термина в исходном языке. Если кратко low coupling это про то, что изменения 1 микросервисе по возможности не должны приводить к масштабным изменениям смежных и далее по цепочке микросервисов. А high cohesion говорит нам о том, что микросервис должен целостно закрывать явно выделенный кусок бизнес контекста. т. е. чтобы изменение бизнес контекста, требующее ИТ доработок в идеале (недостижимом как горизонт), приводило к доработке одного микросервиса. т. е. микросервис не настолько мал, чтобы бизнес задача была сильно больше его, и не настолько зависим от смежников, чтобы любая задача требовала перелопачивания всего ИТ ландшафта.

Собственно в этом суть микросервисной архитектуры, когда в микросервис упаковывается самодостаточный функционал, который можно относительно независимо развивать отдельной командой, с отдельным артефактом поставки и т. д. Где то здесь должны звучать буквы DDD. Но не будем — DDD слишком обширная тема, для небольшой заметки.