Как я делал торговую площадку. Часть 1

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

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

Контекст

Задача была в том, чтобы переписать фронт, обновить дизайн и добавить новые типы торгов.

Проект оказался сложным — я с таким уровнем до этого не сталкивался. Чтобы как‑то справиться, старался искать рекомендованные подходы, читать книги об организации кода и архитектуре и применять это всё по ходу дела.

Теперь вот рассказываю о граблях, которые насобирал.

Проблема 1. Один в поле

Я начинал писать фронт один. Писать сервис одному — значит страдать от недостатка ревью и обратной связи. Рефакторить трудно, спросить совета не у кого (исходники‑то под NDA).

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

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

Проблема 2. Проседающая мотивация

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

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

Но иногда и дробление переставало работать. Мне тогда помогало сесть и начать хоть что‑то делать. Начав с малого, можно втянуться и продолжать работать. Но именно «сесть и начать» бывает сложно.

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

Проблема 3. Отсутствие обратной связи

Если разработка не итеративная, значит какое‑то время результат работы будет уходить в стол. Когда проект не раскатывается на настоящих пользователей, работа может казаться бессмысленной.

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

Проблема 4. Страх запуска

Итеративная разработка — это делаем фичу и деплоим её, когда она готова. Если что‑то пошло не так, узнаем об этом сразу, будет понятно, что вызвало проблему и как её исправлять.

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

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

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

Преодолевать страх — трудно.
Деплоить итерациями — спокойнее.
Понять это на своём опыте — бесценно.

Проблема 5. Фичеризм

Если пилите проект в закрытую, очень велик соблазн добавить как можно больше фич. «Раз уж мы не выкатываемся по частям, давайте сделаем всё‑всё‑всё.» Это — путь в никуда.

Единственное решение, которое помогло нам, — назначить конечный срок запуска и не сдвигать его. Всё, что не успели, перенесли на версию 2.1.

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

Проблема 6. Размер и сложность

Помнить всё — нереально; слишком дофига деталей и нюансов.

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

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

Проблема 7. Собственно запуск

В итеративной разработке релиз — это вполне обыденное дело. Сделали, зарелизили, работаем дальше.

В закрытой разработке релиз — это веха. Жизнь делится на до и после. После релиза, как правило, работы становится больше.

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

Это может стать стресс‑тестом и для вашего продукта, и для вас. А там — привет, пункт 2 ↑

Итог

Это было трудно. Наверное, это был самый сложный проект и по сложности системы, и по поддержанию ритмичной работы с самодисциплиной.

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

Юодкранте, Нида, Прейла, март 2019 →