Skip to content

Процесс разработки

KAlexandra edited this page May 21, 2019 · 13 revisions

Приоритеты

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

Методологии

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

Общение с заказчиком

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

В общении с заказчиком мы стараемся придерживаться максимальной прозрачности нашей работы и частой демонстрации результатов. Взамен на нашу открытость мы просим заказчиков, по возможности, не требовать от нас оценок по срокам. Оценки по срокам негативно влияют на процесс разработки, они замедляют его и формируют у участников проекта искаженные представления о реальности. Если требуется четко уложиться в какой-то определенный срок, мы стараемся следовать подходу Fix Time and Budget, Flex Scope.

Тестирование

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

GitHub

Весь код хранится на GitHub, и не только код. Параметры настройки серверов, скрипты развертывания, документация, вики - все здесь.

AWS

Большинство наших проектов размещены на хостинге Amazon Web Services, и мы активно используем возможности этой платформы.

Автоматизированная настройка серверов

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

Автоматизированная настройка окружения разработчика

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

Continuous Deployment

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

Мониторинги

Мониторинги - важнейшая деталь в обеспечении стабильной работы продакшена. Мы используем Sentry для мониторинга ошибок, Datadog и AWS CloudWatch для мониторинга серверов и приложений.

Только одна ветка - master

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

У нас этот подход не работает, поскольку мы используем Continuous Deployment и релизимся по несколько раз в день. Во-первых, внезапное появление больших блоков нового кода в master нежелательно, поскольку это затрудняет ревью кода и увеличивает вероятность ошибок. Во-вторых, проект движется вперед с такой скоростью, что для разработчиков очень непрактично оставаться изолированными на своей ветке на долгий промежуток времени. К тому времени, когда они начнут вливать свою ветку, master уже будет выглядеть настолько по-другому, что интеграция будет трудоемкой и легко подвержена ошибкам.

Иногда в отдельных исключительных случаях мы создаем дополнительные ветки к master, но стараемся, чтобы они жили недолго и были удалены как можно скорее. Если вы еще не очень хорошо освоились в нашем процессе разработки, то вот примерное правило - как определить, можно ли вам создать новую публичную ветку: "нет, нельзя". Естественно, это относится только к веткам в главном репозитории на Github. Если по каким-либо причинам вам удобно работать с ветками в вашем локальном окружении разработки, то это пожалуйста. Но в главный репозиторий никакие ветки попадать не должны, равно как и следы их использования (коммиты типа "merge").

Code review

Мы используем неблокирующие код-ревью, которые проводятся пост-фактум, уже после попадания кода в master. По нашему опыту, это наиболее оптимальный вариант, который обеспечивает наилучший баланс качества, скорости разработки и комфорта для разработчиков.

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

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

You can’t perform that action at this time.