Инвестиции в ИТ: почему экономия может обернуться убытками

В эпоху цифровой трансформации крупным и средним компаниям важно учитывать не только стоимость разработки ИТ-продукта, но и стоимость его сопровождения и поддержки на протяжении всего жизненного цикла. Экономия может привести к огромным расходам в будущем. Мой телеграм-канал Go HypeLoad посвящен разработке высоконагруженных систем и может быть полезен для тех, кто хочет развиваться в цифровой среде.

Давайте рассмотрим основные причины:

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

Мои рекомендации

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

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

Один штатный разработчик высокой квалификации с рейтом 100$ в час принесет в итоге больше выгоды, чем пять удаленных джунов за 20$ в час. Еще важно понимать, что производительность одного разработчика равна условной единице, но при масштабировании команды производительность не растет линейно. Два разработчика в команде дадут производительность труда равной 1.5. Чем большее число разработчиков в команде, тем производительность каждого из них ниже. Помимо затрат на коммуникацию, начинаются разного рода противостояния в отстаивании своих точек зрения, подковерные игры и размытие ответственности. Здесь появляется необходимость в качественном ресурсном менеджменте.

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

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

Первые два уровня: модульные и интеграционные тесты. Это сфера ответственности разработчика, который реализует требуемый функционал. Модульные тесты – это низкоуровневые, максимально близкие к коду, тесты. Лучшей практикой здесь является методология разработки через тестирование (TDD – Test Driven Development). Модульные тесты можно запускать автоматически средствами CI/CD сразу после сборки. Такие тесты называются Smoke-тестами. С помощью них проверяют основные функциональные возможности приложения после внесения новых изменений на предмет работоспособности.

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

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

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

Мои рекомендации.

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

Недостаточное ведение документации в процессе разработки усложняет понимание кода и логики продукта другими разработчиками. Это затрудняет внесение изменений и требует дополнительного времени для изучения и разбора существующего кода.

Мои рекомендации. Систематизируйте и, по возможности, автоматизируйте создание документации. Не пренебрегайте автогенерацией документации из кода и наоборот. Хорошим примером является автогенерация при работе со Swagger (API документация и инструмент для выполнения запросов). Также, достаточно интересным решением можно назвать Backstage, документация в который автоматически генерируется по репозиторию приложения. Пренебрежение документацией в долгосрочной перспективе приведет к забвению сервиса и превращению его в legacy.

Я буду рад поделиться своими знаниями или обменяться опытом в комментариях к этой статье или в моем телеграмм-канале Go HypeLoad. Большое спасибо, что прочитали мой лонгрид.