Вообще, когда пришла задача по оптимизации на 3 неделе работы в компании, то я сначала дико обрадовался, а потом стало страшно. Такие задачи на самом деле что значат? Что ближайшие 3-4 дня ты проведёшь за исследованием кодовой базы на предмет слабых мест, а затем должен будешь оптимизировать эти слабые места, да ещё и так, чтобы хуже не стало. Это по факту подразумевает глубокое понимание внутренней работы системы, чего у меня пока что нет и что придётся получать в экстренном порядке.
В моём случае оптимизировать надо было ответ от системы на запросы по продвижению ипотечной заявки, при чём не один конкретный эндпоинт, а весь цикл центрального взаимодействия с приложением. Честно скажу — сидел и тупил очень долго. Кропотливо изучал как заявка ходит туда-сюда, какие эндпоинты дёргаются, что в каждом происходит, какие события кидаются, какие подписчики этих событий без надобности выполняются синхронно и так далее.
В итоге после целого дня рефактора получил более-менее вменяемый результат, который завтра надо будет презентовать перед командой, чтобы они хотя бы понимали как ревью проводить, и объяснить выбор своей тактики.
Собственно, мы и подошли к вопросу поста и ответ вроде бы очевиден — снижение нагрузки на систему и снижение времени ответа апишки. Вот только путей достижения этой цели 2:
1. реальная оптимизация — например, минимизация запросов к базе или переписывание целого класса, потому что вся логика помещается в 2 строки
2. мнимая оптимизация — вынос второстепенных синхронных операций в асинх
Мы пока что выбрали второй путь, так как он очевидно проще и его реальный прикладной эффект будет виден пользователям сразу
А вот дальше оказывается на мне уже висят задачи по реальной оптимизации и там я по-полной смогу повес_ел_иться 😀
Добавить комментарий