Главная » Хабрахабр » [Из песочницы] True XP/TDD в Пивотал изнутри: как это выглядит и возможно ли это?

[Из песочницы] True XP/TDD в Пивотал изнутри: как это выглядит и возможно ли это?

Ранее на хабре публиковалась статья о том, как в теории выглядит Xp/Tdd в Пивотал Лабс, и были вопросы о том, возможно\нужно ли это в действительности. Я попытаюсь объяснить, как это выглядит на практике и почему это может быть (внезапно) хорошо.

Это очень отличается от всей энтерпрайс-разработки, которую мне приходилось видеть до этого.
В последние полгода мне пришлось поработать в одном из больших банков на проекте с Pivotal Labs, в их нью-йоркском офисе.

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

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

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

Все требования пишутся в формате when-it-should, под который легко делать тестовые спецификации. Поэтому все, что тебе остается, это спросить его, какая история у нас сегодня в приоритете, и начать ее делать. В процессе обычно один пишет тест, второй имплементацию, потом наоборот. Все спеки пишутся вперед имплементации, если кому-то срочно хочется наоборот, то напарник его поправит.

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

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

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

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

Конкретный технологический стек неважен и варьирует от проекта к проекту, наш текущий цикл выглядит, например, так: jira-ticket >> selenium feature spec >> enzyme\jest spec >> react\redux mock implementation >> react/redux real implementation >> spring boot backend service spec >> backend mock implementation >> spring boot backend real test with oracle \ mq \ whatever.

Ui всегда использует consumer-driven contracts, то есть мы пляшем не от того, что есть в базе, а от того, что мы хотим видеть на форме.

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

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

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

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

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

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

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

Нужна, главным образом, критическая масса маньяков, готовых работать таким образом и бескомпромиссных к предложениям типа: «Ребята, давайте один день играть в сику, а один день разматывать кабель», «давайте-ка по-быстрому в продакшен» и т.п. Когда видишь работающую систему, понимаешь, насколько трудно ее внедрить и насколько много противодействия извне. Если один человек из команды опаздывает, отказывается объяснять решения, или писать тесты, или разбивать истории — система теряет смысл и демотивирует остальных. И нужно быть готовым принимать ее целиком. Система сейчас получает быстрое развитие на Уолл-Стрит, хотя пока неясны пределы ее возможностей. Поэтому должна быть воля и ресурс для энфорсмента. Возможно, вскоре она поглотит традиционные способы разработки, по крайней мере, в привычном банковском энтерпрайзе.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Будущее рабочих мест. Главное из отчета Всемирного экономического форума

Согласно отчёту Всемирного экономического форума The Future of the Jobs 2018 уже через четыре года 75 миллионов рабочих мест будут упразднены, но их заменят другие 133 млн. Но страх того, что «роботы заменят людей», все ещё не соответствует реальности. Формулировка ...

Полезные советы по использованию HyperLynx DDR Wizard для анализа QDR4

Quad Data Rate (QDR-IV) является стандартом высокопроизводительной памяти для сетевых применений и идеально подходит для нового поколения сетевых устройств, коммуникационного оборудования и вычислительных систем. Этот блок способен обработать все одноразрядные ошибки памяти, в том числе, вызванные космическими лучами и альфа-частицами. ...