Как я делал торговую площадку. Часть 1
Последние джва полтора года я работал в закрытом режиме над фронтендом для последнего проекта. Мы не могли себе позволить до релиза пилить фичи итеративно и выкатывать их по мере готовности. Нам нужно было полностью переделать сервис и выкатить новую версию разом.
В этом посте я расскажу, почему это трудный путь, покажу ошибки, которые я допустил, и посоветую по возможности избегать такого подхода.
Контекст
Задача была в том, чтобы переписать фронт, обновить дизайн и добавить новые типы торгов.
Проект оказался сложным — я с таким уровнем до этого не сталкивался. Чтобы как-то справиться, старался искать рекомендованные подходы, читать книги об организации кода и архитектуре и применять это всё по ходу дела.
Теперь вот рассказываю о граблях, которые насобирал.
Проблема 1. Один в поле
Я начинал писать фронт один. Писать сервис одному — значит страдать от недостатка ревью и обратной связи. Рефакторить трудно, спросить совета не у кого (исходники-то под NDA).
Сила командной работы в том, что все погружены в контекст. Каждый в команде знает обо всех компромиссах и слабых решениях. Сами решения появляются не в одной голове, а свежий взгляд на задачу всегда помогает найти более простое решение.
Если вы пишете сервис в одиночку, этого будет сильно не доставать. И чтобы при этом поддерживать работу, надо обладать очень сильной самодисциплиной.
Проблема 2. Проседающая мотивация
Если вы пишете большой сервис в закрытую, неизбежно столкнётесь с состоянием, когда объём работы будет казаться неподъёмным, а планы перестанут вас убеждать, что вы справитесь. В такие моменты сильно проседает мотивация.
Чтобы не терять фокус и продолжать, я дробил этапы и задачи на более мелкие этапы и задачи. Так прогресс был более заметен, и впечатление непосильности на время отступало.
Но иногда и дробление переставало работать. Мне тогда помогало сесть и начать хоть что-то делать. Начав с малого, можно втянуться и продолжать работать. Но именно «сесть и начать» бывает сложно.
Короче, марафоны, особенно закрытые, подходят не всем. Тщательно обдумайте решение, перед тем как вписаться в марафон.
Проблема 3. Отсутствие обратной связи
Если разработка не итеративная, значит какое-то время результат работы будет уходить в стол. Когда проект не раскатывается на настоящих пользователей, работа может казаться бессмысленной.
Без обратной связи от мира трудно убедить себя, что есть реальная польза от работы. Без них может быть туго с удовлетворением от результата. Ну а без него — см. пункт 2 ↑
Проблема 4. Страх запуска
Итеративная разработка — это делаем фичу и деплоим её, когда она готова. Если что-то пошло не так, узнаем об этом сразу, будет понятно, что вызвало проблему и как её исправлять.
В случае с закрытой разработкой всё не так. Вы пишете большой набор фич, из которых отвалиться может что угодно. Чем больше проект и чем дольше времени он был закрыт, тем больше страх запуска.
Дело не только в страхе, что в коде ошибки, но и в целом за продукт. Дизайн может вызывать отторжение, пользовательские шаблоны могут поломаться, где-то точно появятся ошибки, которые будет трудно отследить.
Если логику можно покрыть тестами и частично снять когнитивную нагрузку, то с «предвосхищением» реакции пользователей на новую версию ничего поделать нельзя. Только запуститься, скрестить пальцы и ждать.
Преодолевать страх — трудно.
Деплоить итерациями — спокойнее.
Понять это на своём опыте — бесценно.
Проблема 5. Фичеризм
Если пилите проект в закрытую, очень велик соблазн добавить как можно больше фич. «Раз уж мы не выкатываемся по частям, давайте сделаем всё-всё-всё.» Это — путь в никуда.
Единственное решение, которое помогло нам, — назначить конечный срок запуска и не сдвигать его. Всё, что не успели, перенесли на версию 2.1.
Занятно, что чем больше времени потрачено на разработку, тем легче согласиться на ещё какую-нибудь фичу. Ведь «мы потратили столько времени, не страшно потратить ещё немножечко». Но из таких «немножечек» могут складываться недели и месяцы. Не надо так.
Проблема 6. Размер и сложность
Помнить всё — нереально; слишком дофига деталей и нюансов.
Важно решения документировать, но важнее всего — описывать причины, по которым это решение принимается. Иначе велика вероятность, что потом вы не вспомните, почему какая-то фича работает именно таким образом.
Переработка архитектуры и развязывание сущностей помогло нам немного сбросить эту нагрузку, но перерабатывать архитектуру — трудно, больно и затратно. По возможности контролируйте это с самого начала.
Проблема 7. Собственно запуск
В итеративной разработке релиз — это вполне обыденное дело. Сделали, зарелизили, работаем дальше.
В закрытой разработке релиз — это веха. Жизнь делится на до и после. После релиза, как правило, работы становится больше.
Если сервисом уже пользовались, и новая версия была в закрытой разработке, то бэклог будет расти с такой скоростью, что я бы с удовольствием придумал какое-нибудь сравнение, но не буду даже пытаться.
Это может стать стресс-тестом и для вашего продукта, и для вас. А там — привет, пункт 2 ↑
Итог
Это было трудно. Наверное, это был самый сложный проект и по сложности системы, и по поддержанию ритмичной работы с самодисциплиной.
После релиза стало веселее: появились новые люди в команде, свежий взгляд на сервис и всё такое. Но эти полтора года до — стали очень ценным опытом: многому за это время научился и многое испытал на себе.