Эволюция команды разработки

Весной 2019 года меня пригласили руководить разработкой в небольшой стартап, занимающийся обработкой Big Data.

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

Команда разработки включала в себя 10 сотрудников: тимлид, front-end разработчики, back-end разработчики, системный администратор и DevOps. Стэк разработки: Python, PHP, JavaScript. Мои глобальные задачи были стандартны, но это не делало их простым. Я упорядочил их по порядку решения задач:

1. Повысить качество и отказоустойчивость инфраструктуры

2. Повысить квалификацию разработчиков

3. Повысить качество ПО

Повышение качества и отказоустойчивости инфраструктуры

Проблема №1: Команда работала “по старинке”.Каждый разработчик сам управлял локальным окружением разработки. Это приводило ко всем знакомой ситуации при возникновении ошибок на production’е: у меня локально работало. Окружение должно быть единым для всех ваших окружений. С приходом контейнеризации (в частности, Docker’а) в массы, эта задача стала легко решаемой.

Решение: Контейнизируйте ваши приложения. Выберите единую ОС для вашего базового образа (на тот момент у нас был Ubuntu 18.04 LTS). Устанавливайте 3-rd party пакеты с точной версией, вплоть до хотфиксной. Пусть поддержкой занимаются системные админстраторы и DevOps’ы, разработчикам делать там нечего.

Проблема №2: Много self-hosted сервисов, мало системных администраторов

Все проекты и их компоненты были на выделенных серверах, которые поддерживались двумя (а долгое время одним) системным администратором. Большая часть работы была рутинным админством: тут "подкрутить", там "отшлифовать".

Решение: Освободите руки системного администратора от рутинных задач насколько это возможно. Автоматизируйте свои процессы с помощью Terraform ^[1] и Ansible ^[2]. На уровне малого бизнеса/стартапа зачастую дешевле делегировать часть работы, чем нанять еще одного системного администратора. Возьмите managed СУБД и K8s, за одно решив таким образом такие проблемы как отказоустойчивость, масштабируемость и админством этой инфраструктуры.

Проблема №3: Вшитые в код ключи/пароли/сертификаты (секреты) от production сервисов

Решение: Внедрите систему хранения секретами, такой как Vault ^[3]. Настройте политику доступа к этим данным. Перенесите все секреты из кода в хранилище и запрашивайте их при инициализации приложения.

Повышение квалификации разработчиков

На момент моего прихода в команде были в основном junior разработчики.

Проблема №1: Низкая квалификация разработчиков

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

Решение: Оставьте только талантливых людей (даже если они junior’ы), которые быстро учатся и самое главное, хотят учиться. На остальных не тратьте время. Новичков вполне могут позволить другие крупные и состоявшиеся компании. Наберите вместо 5 новичков 2 хороших специалиста, которые будут качественно выполнять свою работу. Старайтесь находить тех, у кого вы бы сами могли чему-нибудь научиться в узкой области.

Проблема №2: Каждый разработчик пишет код в своем стиле

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

Решение: Дирижируйте свою команду. Прививайте разработчиков к единому стилю написания кода. Используйте линтеры типа we-make-python-styleguide ^[4] (сборник плагинов к flake8) для поддержания единого стиля.

Проблема №3: Отсутствие технологического развития

Разработчики не развиваются в технологическом плане, решая задачи так, как они привыкли их решать.

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

Повысить качество ПО

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

Проблема №1: Плохо спроектированный код

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

Решение: Внедрите DDD ^[5] и Twelve-Factor App ^[6].

Проблема №2: Классы, классы и еще раз классы по всюду

Проектировать большой набор абстракций с одной реализацией не есть хорошо. Не нужно использовать классы только ради группировки вашей бизнес-логики

Решение: Для группировки сойдут модули и пакеты. Функцию не обязательно оборачивать в класс. Прочитайте о YAGNI ^[7], KISS ^[8], а также о функциональном программировании ^[9].

Проблема №3: Слишком сложные для понимания автотесты

Сразу взять и понять как работает та область, которой вам поручили заняться сложно.

Решение: Описывайте логику в виде BDD ^[10] сценария. Вникать в предметную область гораздо проще прочитав его сценарии, чем программный код.

Заключение

Перемены, описанные выше происходили в течение 1 года. По всем 3 пунктам удалось добиться хороших результатов. Инфраструктура и приложения стали реже падать, удалось снизить кол-во инцидентов в 10 раз. Системный администратор и DevOps стали крепче спать по ночам. Кодовая база всех проектов стала похожей, что позволило новым разработчикам быстро переключатся из одного проекта в другой. Укрепился командный дух. И не мало важно, руководство осталось довольным.

С наступающим, Новым годом!

Автор: Tigran Muradyan

Источник ^[11]