Инженерная культура в IT компаниях

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

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

Софт скиллы

Сейчас развитые софт-скиллы нужны абсолютно всем разработчикам.

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

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

Тайм-трекинг: основные причины логать время

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

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

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

Как только вы определились с выбором СI/CD системы, выбрав из целого ряда вариантов, таких как Circle CI, Travis CI, GitLab CI или даже Jenkins, вы сможете ее использовать для настройки конвейеров (пайплайнов). Система поможет вам понять что не так с изменениями, которые были внесены в код.

Команды, внедрившие в свою работу CI/CD, более эффективны, так как данный подход помогает им автоматизировать рутинные задачи и запустить следующие инструменты:

1. Линтеры помогают убедиться, что вся команда следует одному руководству по стилю языка. Кроме того, некоторые линтеры могут помочь предотвратить проблемы безопасности и провести статический анализ кода. Причина, по которой необходимо иметь линтеры на вашем CI/CD конвейере — это обратная связь о том, что не так с качеством кода.
2. Автоматический запуск тестов необходим в CI/CD конвейере. Его настройка поможет сэкономить очень много времени разработки.
3. Сделайте собственную сборку Docker контейнера и автоматически загружайте ее в закрытый выбранный вами реестр.
4. Деплоймент — это процедура развертывания программного обеспечения или среды разработки, основанная на вашем git-flow.

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

Заключение: CI/CD пайплайны — это один из основных показателей выстроенной инженерной культуры в вашей команде. Отлично, если они у вас есть и вы их поддерживаете, хорошо, если вы планируете их настроить, и плохо, если вы вообще не планируете их внедрять. То же самое относится и к code review.

Проектный подход к разработке и документация

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

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

1. Сокращение времени на онбординг в проект. Команда может передавать знания при помощи документов. Нет необходимости говорить о культуре компании, рабочих процессах или графике работы — все уже задокументировано, если вы используете подход обмена знаниями в масштабах организации. Для инженерной команды с помощью документации можно сократить время, затрачиваемое ведущими разработчиками на рассказ о стратегии развертывания программного продукта, используемом стеке и протоколе связи между сервисами.
2. Уменьшение времени выхода продукта на рынок. Когда команда разработчиков закончит проект и будет готова развернуть его в продакшн, достаточно будет простого файла readme с документацией. Docker и docker-compose также будут полезны. Команда девопсов легко развернет проект на проде с помощью этих файлов.
3. Уменьшение количества вопросов к команде, а значит — экономия времени для более важных задач.

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

Управление командами разработчиков: коммуникации в распределенных командах

Подход, основанный на проектировании

Любой сервис начинается с проектирования API. API нет только у нерабочего сервиса. Опытные инженеры-программисты стремятся задокументировать API в самом начале и делятся им с другими командами. Таким образом, другие команды не будут от них зависеть. Они смогут создавать серверы-заглушки для продолжения своей работы. Удобно, что у разработчиков есть swagger и gRPC для этих целей. Команды могут провести встречу и обсудить как будет спроектирован сервис и дизайн API для него, и начать работать независимо друг от друга, пока не будет достигнут момент интеграции.

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

1. Обсудите изменения с командой и убедитесь, что они будут работать (приносить пользу).
2. Внесите изменения в документацию (swagger или proto файл): вам необходимо подтверждение изменений.
3. Продолжайте работать

Подход, основанный на проектировании — это необязательный к соблюдению этап в моей статье, но, по моему опыту, он ускоряет время разработки (см. документацию).

Мониторинг и наблюдение

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

Что сделает ваш сервер наблюдаемым?

1. Правильно собранные логи. Логи должны давать вам достаточно информации, чтобы понять, что идет не так. Вы можете использовать Elasticsearch + Logstash + Kibana для сбора логов от приложений в вашем сервисе.
2. Перехват ошибок. Необходимо знать, с какими ошибками сталкиваются пользователи и устранять их по мере возникновения.
3. Системные метрики. Вам необходимо получать информацию об использовании процессора/сетей/оперативной памяти/дисков в производственной среде.

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

Отлично, если команда заботится о мониторинге и улучшает качество наблюдения за своими системами.

Экономическое мышление

Точка зрения и подход к анализу того, как устроен мир, путем сравнения стоимости действия с получаемой выгодой. Изучение экономики — это процесс экономического мышления по вопросам, связанным с проблемой дефицита.

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

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

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

Как избежать проблем микроконтекста в команде?

Заключение

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