dev-speed

5 способов увеличить скорость разработки программного обеспечения

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

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

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

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

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

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

Вложение усилий в скорость итераций со временем увеличивает скорость работы команды разработчиков.

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

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

Итак, вот что мы сделали…

Монорепозиторий

У нас было три репозитория для приложения, прежде чем мы объединили их в один. Репозиторий для пользовательского интерфейса, API, инфраструктуры приложения и некоторых других, включенных в качестве подмодулей.

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

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

Читаемый код

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

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

Мы потратили время на то, чтобы упростить запросы, используя более читаемый синтаксис запросов под названием Elasticsearch DSL. Затем мы задокументировали их поведение так, чтобы даже школьник смог это прочитать.

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

Быстрая локальная разработка

Наше приложение, как и многие другие, использует облачные сервисы AWS, такие как LambdaKinesisSQS, и API Gateway.

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

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

Мы потратили свое время на создание процесса, в котором нам не нужно было бы внедрять наши изменения для получения отзывов. Мы использовали комбинацию сервисов docker-compose и Localstack. Теперь разработчик может запустить все приложение на своей рабочей станции с помощью одной команды, docker-compose up.

Эффективные CI/CD-пайплайны

Наши пайплайны непрерывной интеграции были медленными и подверженны ошибкам.

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

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

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

Комбинация непрерывной интеграции/доставки — это основа разработки программного обеспечения. Любые простои или неэффективность напрямую негативно сказываются на скорости разработки. Поэтому операции должны проходить гладко и эффективно.

Мы адаптировали культуру dev-ops в нашей команде для решения проблем и дальнейшего улучшения процессов, и это значительно окупилось.

Стабильные автоматизированные интеграционные тесты

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

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

Мы решаем эту проблему, используя механизмы повтора, основанные на определенных кодах ошибок HTTP, выдаваемых API. Поэтому, когда запрос API из теста получал 404, он ждал секунду, а затем повторял запрос API.

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

Заключение

Выполненные улучшения постепенно увеличили количество задач, которые мы завершили за спринт. Это не потребовало дополнительных часов работы или каких-то поощрений.

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

Спасибо, что нашли время прочитать эту статью!

Перевод с английского. Источник.