Грустная история о том, что каждый программный код переписывается хоть раз

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

История, описанная ниже, перевод статьи с Medium.com , которая вызвала бурное обсуждение внутри коллектива моей компании (я даже сохранил для вас некоторые комментарии). Но, я уверен, рассказ покажется до боли знакомым очень многим читателям Хабр.

Каково это – быть продакт-менеджером, который противостоит инженерному хаосу?

Начальник отдела разработки созвал всех на собрание: 

“Послушайте, – говорит он, – у нас серьезное отставание от графика. Множество зависимостей не поддерживаются в коде. У нас нет тестового покрытия”. Он делает паузу, как вам кажется, чересчур драматическую и продолжает: “Нам нужно переписать код”.

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

“Что вы имеете в виду под “переписать код”?” – спрашиваете вы.

Глава отдела разработки пожимает плечами: “Мы используем мультитул версии 1.6, – говорит он, – но версия 4.3 была выпущена на прошлой неделе, поэтому мы должны быть как минимум на версии 4.x”.

«Хорошо, – скажете вы, – повлияет ли это на фичи, которые мы уже добавили в список?»

“Что ж, да, мы не можем сделать все и сразу”, – говорит он измученным тоном человека, которому надоело иметь дело с людьми, не понимающими таких простых истин. Вам уже все понятно, поэтому переходите сразу к делу и спрашиваете: “Сколько времени займет переписывание кода?”

“Трудно сказать, – пожимает плечами он, – логика уже заложена в приложении, поэтому нам не придется с этим разбираться. Но, на самом деле, нам нужно переписать его с нуля, потому что мы используем Sprockets для сборки и выпуска”. Он продолжает, усмехнувшись: “Вы можете поверить, что мы используем эту штуку?”

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

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

Вы не собираетесь выпускать пар при помощи пассивно-агрессивных комментариев. Все остальные так делают.

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

«Для того чтобы проект был актуальным и поддерживаемым желательно постоянно заниматься обновлением зависимостей, у нас этим занимается архитектор. Если этого системно не делать, то в какой-то момент происходит накопление обновлений до критической точки и простой переход с версии 1 до 2 превращается в переход от версии 1 до 5 и в переписывание всего проекта.

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

Руководитель мобильной разработки Мегаплана, Игорь Суховерхов

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

Через неделю вы снова встречаетесь. «Как продвигаются дела с кодом?», – спрашиваете вы. 

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

Проходит месяц. Вы снова встречаетесь:

«Как идут дела?», – спрашиваете вы.

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

Они стреляют друг в друга из игрушечного пистолета. И их раздражает, что в офисе нет стола для настольного тенниса.

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

«Не самое страшное в этой истории. Я, например, играю на гитаре или хожу к холодильнику. Раньше во времена до карантина, когда мы работали в офисе, ходили с друзьями играть в кикер и на прогулку за кофеечком. А ещё дартс, тренировал меткость».

Руководитель мобильной разработки Мегаплана, Игорь Суховерхов

Младший разработчик объясняет несколько преимуществ Spasm. Это MVVM(Model-view-viewmodel) паттерн, тогда как Doohickey – это MVC(model-view-controller) паттерн, который действительно старомоден. Вы ждете своей очереди и вежливо спрашиваете о некоторых срочных доработках, которые нужно добавить в продукт.

“О да, – говорит младший разработчик, – сделаем. Мы можем добавить их в очередь”. Вы чувствуете облегчение. Напоследок хорошие новости. Недели ожидания окупились.

“О нет, – вмешивается руководитель отдела разработки, – они говорят о старом дер… – он смотрит вам прямо в глаза, — я имею в виду устаревший сайт, а не новую сборку”.

“Ой, дружище, – говорит младший разработчик, – это такая головная боль”.

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

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

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

1) Делайте всё вовремя и не затягивайте с обновлениями.

2) Используйте архитектурные подходы, которые позволяют вносить такие изменения без изменения пользовательского опыта и бизнес логики. Например, гексагональная архитектура.

3) Считайте все в деньгах. В какой-то момент стоимость поддержки начнет кратно расти – это знак, что пора что-то делать.

4) Если проект хочет развиваться и масштабироваться, а его код устарел и не поддерживается – еще один сигнал, что пора заняться рефакторингом

Вы смотрите на экран. Но даже на надеетесь увидеть там законченную работу.

В следующий раз, когда вы встретитесь, у руководителя отдела разработки будет готова демо-версия. “Мы еще не закончили работу над пользовательским интерфейсом, – говорит он, размахивая рукой, – UX-дизайнер не вернулся к нам с готовым результатом, и мы “на пока” хотели оставить прототип с низкой точностью воспроизведения, чтобы вы знали, что работа еще не закончена”.

Вы смотрите на экран. Но даже не надеетесь увидеть законченную работу.

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

Она делает несколько глотков кофе, делает паузу, чтобы вдохнуть его аромат.

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

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

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

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

Руководитель мобильной разработки Мегаплана, Игорь Суховерхов

Креативный директор не согласна: “Но ведь сейчас прекрасная возможность!”  Затем, резко сменив тему: “Поговорим об аналитике?”

Платформа аналитики, которая генерирует ежемесячные отчеты о пользователях для руководства, не подходит для этой цели. “Она не позволяет проводить A/B-тестирование, – говорит креативный директор, – или отслеживать путь наших пользователей в течение сессий”.

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

“Я предлагаю использовать Analogix”, – говорит креативный директор. Начальник отдела разработки быстро изучает этот сервис и видит, что для Spasm есть плагин, так что он за. 

«И можем ли мы добавить его на текущий сайт, чтобы сравнить аналитику?» – спрашивает креативный директор.

Глава разработки резко вздыхает, словно он сантехник, который смотрит на протекающую трубу: “Это займет кучу времени”. 

“Из-за переключения контекста?» – предполагаете вы.

«Да, – говорит он, – это добавляет когнитивную нагрузку”.

“А как насчет GDPR (общий регламент по защите данных)?” – спрашивает кто-то в комнате. Все согласны с тем, что нужно обойтись без юристов и защиты данных.

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

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

“Как вы выполняете другие задачи?”, – спрашиваете вы: “Такие как импорт XML-файлов”. Исправление ошибки импорта XML было одной из тех задач, решения которой вам удалось добиться в прошлом спринте.

“О, это просто самые распространенные пути пользователя, – говорит креативный директор, – мы еще не углубились во все другие пути”.

Прошло четыре месяца, и все, что вам смогли показать – это веб-сайт, на котором все написано черным шрифтом Times New Roman на белом фоне и красиво оформленное изображение, иллюстрирующее две из 378 фичей. 

Залог хорошего планирования:

1) Точность оценки задач. В scrum это приходит с опытом: каждый новый спринт команда всё лучше и лучше оценивает свои возможности.

2) Дедлайны и сроки – работа не должна быть бесконечной.

3) Измеримость конечного результата.

Ну, и конечно хороший проджект-менеджер 🙂

На следующей встрече начальник отдела разработки сообщает вам, что уходит на работу в Dunkr. “Это стартап. Как Uber, только для одежды”, – говорит он. Судя по всему, они используют Spectral Spasm. Это новая версия Spasm, которая гораздо круче предыдущей. Он в восторге от новой должности. “Мне даже дали опционы на акции”, – говорит он вам.

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

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

Руководитель мобильной разработки Мегаплана, Игорь Суховерхов

Две недели спустя вы встречаетесь в кофейне с новым руководителем инженерного отдела. “У меня есть некоторые мысли”, – говорит она. Вы готовитесь ее выслушать. Еще одно изменение приоритетов, тот же контент, переписанный в другом формате или стиле. Вы уже забыли, перешли ли они только что на Jira или, наоборот, ушли с нее.

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

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

“Несмотря на то, что текущий сайт выглядит немного устаревшим, – говорит она, – он работает уже много лет. У него много недоработок. Мы могли бы работать над его улучшением поэтапно, без необходимости каждый раз проводить масштабные изменения и беспокоиться о том, что мы случайно можем что-то пропустить”.

“Сохраняй спокойствие”, – думаете про себя. Затем вы обращаетесь к ней и говорите, что у вас все получится, если будет уделено особое внимание списку нерешенных ошибок. Она соглашается с вашими условиями. Вы – менеджер по продукту, генеральный директор продукта, в каком-то смысле, даже политик. Вы рассказываете ей о текущем списке ошибок и доработок, которые у вас уже есть. “Просто отправьте их в текущем виде, – говорит она, – Я не хочу заставлять вас выполнять дополнительную работу”. 

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