Как сократить количество кода в десятки раз и пережить пятничный деплой: опыт frontend-разработчика Creative

Всем привет! Сегодня на личном опыте хочу рассказать, как непродуманная архитектура может привести к разрозненности приложения, полному нарушению принципа DRY (Don’t repeat yourself) и колоссальным трудозатратам при изменении функционала. А ещё поднимем знакомую всем разработчикам тему того, как всё может пойти не по плану в и без того сложном проекте.

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

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

Суть системы – дать возможность объединять коллег в команды, у которых есть «комнаты». В этих «комнатах» можно создавать папки и документы с вариативной областью видимости: всей «комнаты», всего проекта, отдельной папки. Конечно, всё это было «присыпано» кучей прав. Нужно было настроить логику этой системы и реализовать удобное коллективное редактирование доков.

• Механизмы внутри системы были разнесены отдельно, и каждой сущности присвоен свой файл, который отвечал только за неё. В итоге у нас оказалось порядка 5-7 файлов, в каждый из которых были импортированы другие миксины. Это приводило к полному беспорядку внутри компонента.

• Один и тот же миксин нельзя было использовать при работе десктопной и мобильной версий. В десктопе было контекстное меню, а в мобилке – любой клик (реально любой, типа event-ов) провоцировал конфликты передаваемых данных. Получалось, что исходный единый код попросту не мог работать без определённых доработок.

Ниже представлен пример одного из файлов, с которым система работала (илл. 1). Замечу, что на нём показан всего один тип сущности, а таких у нас было пять – с разными файлами для каждого.

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

После анализа всех проблем я решил, что лучше всего привести все функции в тип, которому будет всё равно, каким способом мы его вызываем – будь то contextMenu или простой клик. На итоговое решение было потрачено два дня, т.к. запутанность данного кода была довольно сильная + ко всему на каждый запрос был разный эндпоинт, с чем, конечно, пришлось смириться.

В итоге код в случае контекстного меню стал выглядеть так (илл. 2):

А в случае простого клика – так (илл.3):

Всё было хорошо, я протестировал функционал и убедился, что он работает. Был вечер пятницы, и ничего не предвещало беды. Но всё изменил ОН. Пятничный деплой. Бекеры решили закрыть свои задачи перед выходными, и когда в понедельник утром ничего не подозревающий я пришёл на работу, меня ждало море тикетов от тестировщиков. Функционал не работал!

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

Покажу примеры того, как это было (илл. 4), и как я переделал всё после деплоя (илл.5):

• 5 эндпоинтов были заменены всего одним.
• Благодаря созданию универсальных миксинов было убрано 963 строки лишнего кода.
  
• Дальнейшая поддержка приложения упрощена.
  

• Найдены и пофиксены проблемы с производительностью.

Напоследок хочется сказать, что именно старые системы, которые нам нужно дописывать/переписывать, учат нас читать чужой код и очень сильно бустят хард скилы. Поэтому не бойтесь улучшать то, что поначалу не хочется даже трогать. А в случаях, когда по какому-то стечению обстоятельств, вам нужно это переделать – фиксируйте свои успехи, замечайте их. Это ваш рост и развитие!

На этом всё, буду рад ответить на ваши вопросы в комментариях.