Экстремальное программирование: «ковбойский багфикс на продакшне»

Пару слов о себе: мой опыт в веб-разработке — 12 лет. Я отвечаю за техническую составляющую компании Sovtes; в команде со мной работают 4 сотрудника.

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

Постановка задачи

Как правило, задачи поступают от продакта Олега Рудковского: «Мне надо сделать учет расхода топлива для нового клиента». С этого момента я начинаю «мучить» Олега своими вопросами и выяснять реальное положение вещей: какие конкретно бизнес-задачи преследует заказчик.

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

Согласовав сроки и приоритеты, мы обсуждаем допустимые отклонения функционала. То есть выкидываем то, чем можно пожертвовать для более оптимальной реализации. И тут же намечаем 2-3 варианта реализации: быстрый (который мы выбираем в 99%), традиционный нормальный и усложненный «с забеганием вперед».

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

Кодинг

Принимаясь за работу, я всегда делаю упор на получение 80% результата за 20% времени. Остальные 20% результата зачастую можно изменить так, чтоб они не занимали 80% времени, или вообще отложить.

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

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

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

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

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

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

Мы очень скрупулезно подходим к кодингу — стараемся не допускать багов из-за халатности. Кодим бдительно и потом мы сразу же тестируем свою работу на предмет исправности.

Таким образом, мы передаем продакту и тестерам функционал, который, как правило, уже готов на 100%. Олег и тестировщики делают финальную формальную проверку функционала.

Релиз

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

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

Пример

Вот реальный пример экстремального программирования в действии.

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

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

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

Как только появится необходимость клиентам управлять этими плательщиками, тогда и будет интерфейс управления и записи в базе.

Вывод

Почему такой подход работает:
— Имеем быстрый ощутимый результат;
— Тратим время эффективно.

Делайте только то, что нужно реально сейчас и не тратьте время на разработку функционала, который не нужен. Делайте code reviews регулярно и стремитесь к нулю багов в коде.