Удаление 50 000 строк кода за 3 дня

На прошлой неделе я удалил более 50 000 строк из кодовой базы Юпитер. Весь удаленный код ранее использовался в рабочей среде, обеспечивая работу нашего веб-приложения, которое ежедневно обслуживает сотни тысяч запросов. Удаленный код составляет около 70% нашей кодовой базы внешнего интерфейса, написанной на JavaScript с использованием React и Next.js.

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

Мы создаем Jovian с 2019 года, и за эти годы платформа прошла различные этапы эволюции. Мы добавляли новые функции, страницы, кнопки и настройки всякий раз, когда они нам были нужны, но редко задумывались об удалении чего-либо (кто это делает?). Мы приложили сознательные усилия, чтобы приложение было простым и удобным в использовании, но, тем не менее, оно накопило много «функционального долга».

Я где-то читал, что более 80% функций типичного программного приложения почти никогда не используются, и вспомнил, что видел этот снимок экрана, показывающий все инструменты, доступные в Microsoft Word:

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

Несколько недель назад я начал работать над экспериментальное переписывание нашего веб-приложения, созданного с использованием новейшей версии Next.js и развернут в Страницы Cloudflare. Я быстро понял, что полноценный переписать с нуля не получится. На пересборку всего приложения уйдет несколько месяцев, и оно почти наверняка будет пронизано сотнями ошибок. Миграции «большого взрыва» редко срабатывают, а даже если и случаются, то занимают гораздо больше времени, чем планировалось. Я испытал это на собственном опыте, работая в Twitter, где потратил несколько месяцев на миграцию кода с Ruby on Rails на Scala.

Однако возрастающая миграция представляла собой ряд проблем. Новые страницы, которые я создал, были довольно простыми по структуре и содержанию, в то время как существующие страницы нашего приложения имели несколько интерактивных вкладок, кнопок и виджетов. Наше существующее веб-приложение использует API REST, обслуживаемые серверной частью Python, тогда как я хотел использовать действия сервера взаимодействовать с нашей базой данных непосредственно из Next.js, чтобы сделать приложение быстрее, а также исключить затраты на хостинг серверной части. Для этого потребуется перенести сотни конечных точек API, содержащих десятки тысяч строк нетривиальной бизнес-логики, с Python на JavaScript, чего мне не хотелось делать.

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

Затем, несколько дней назад, меня осенило, что я могу двигаться быстрее, сбросив вес. Я мог удалить ненужные виджеты и кнопки с экрана, перенести их в новый стек (к счастью, Next.js поддерживает инкрементная миграция), а удаленные элементы добавьте позже. Однако то, что последовало за этим, можно охарактеризовать только как кровавую бойню:

Я не собирался удалять две трети кодовой базы. Я хотел удалить ровно столько, чтобы начать миграцию одного модуля. Я просмотрел посещения страниц для каждого модуля за последние 30 дней в Google Analytics, чтобы определить, с чего начать. Хотя я знал, что некоторые страницы посещаются реже, чем другие, я был удивлен, увидев, что существуют модули, на долю которых приходится менее 0,1% посещений страниц. Это означало, что я мог полностью удалить их, не затрагивая 99,9% пользователей. Я мог удалить целые каталоги, содержащие десятки файлов и тысячи строк кода.

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

Удалив целые редко используемые модули, я приступил к удалению отдельных экранов и всплывающих окон, на которые приходилось менее 0,5% трафика. И снова я был удивлен, обнаружив, что сотни файлов можно удалить, не затрагивая 99,5% пользователей. На самом деле это подействовало на них в хорошем смысле. Пять вкладок превратились в три, затем в две, затем в одну, а в этот момент вкладки можно было вообще удалить со страницы. Многие страницы теперь имели более простую структуру и одно основное действие. Меньшее количество вызовов API привело к более быстрой загрузке страниц и переходам между экранами. Это было прекрасно!

После того, как все ненужные модули и страницы были удалены, я начал дальше копаться в Google Analytics, чтобы определить, как часто используются функции на оставшихся страницах. Я обнаружил несколько функций, которые редко использовались, кнопки, на которые почти никогда не нажимали, и пункты меню, которые даже никогда не видели. Итак, я приступил к их удалению. Чем больше я забирал, тем больше мне нравилось то, что осталось. Я удалил несколько боковых панелей, раскрывающихся меню, кнопок, виджетов, всплывающих окон, а также внутреннее состояние приложения и условную логику, необходимую для их поддержки. Это также сделало код более понятным, что должно еще больше облегчить миграцию. То, что поначалу казалось усилиями в несколько месяцев, теперь кажется тем, что я могу сделать за пару недель.

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

«Совершенство достигается не тогда, когда больше нечего добавить, а когда нечего отнять» — Антуан де Сент-Экзюпери