будучи единственным frontend разработчиком на проекте

Контекст🤓

Я работал всегда в команде 2-3 фронтенд разработчиков и привык к процессам, например как код ревью. В голове всегда осознавал, что говнокод на скорую руку на ревью никто не пропустит, даже есть очень большой соблазн - всегда приходилось отметать эту мысль в сторону😁 Что же произошло на последнем месте?

Я пришел в компанию на замену единственного фронта и тут сознание немного перевернулось. Теперь руки развязаны сделать код на скорую руку, ведь нет тех самым ревьюеров, которые как ангелы на плече шептали тебе на ухо: говнокод не пройдет ревью, будешь переписывать😁 И сначала даже мне такое понравилось, ведь как мне показалось это экономит время, нервы и увеличивает скорость релизов… Я глубоко ошибься, оказалось совсем наоборот. Это увеличило время на рефакторинг кода, добавило горсть нервов на исправление багов на проде, ну и соответственно на откаты после релизов. И я остановился и подумал какие шаги могу предпринять со своей стороны, чтобы минимизировать все эти проблемы.

Шаги по оптимизации качества и стабильности фронтенда📋

Я выделил основное, что применял в работе, если у вас есть какие-то свои техники - буду рад почитать.

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

Ревью через ИИ🤖 - я люблю использовать ИИ как инструмент и в данном случае он подходит идеально. Тут нужно давать хорошие промпты со всем контекстом задачи иначе может случиться так что часть бизнес логики он посчитает лишней, но он может довольно хорошо найти подводные камни в коде, особенно когда глаз уже замылен от выполнения задачи и важно мнение со стороны.

Тестирование🛠️ - я заинтересован, чтобы задача прилетала в прод, а в идеале и к QA без багов, поэтому принял в привычку проверять свою задачу на фронте по основным кейсам на всем пути задачи до прода включительно. Речь идет не о том, чтобы делать работу за QA, а в том, чтобы найти потенциальные проблемы до того, как их найдет пользователь.

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

E2E тестирование🛠️ - я предложил создать систему, которая будет проходить диагностику для детей от начала до конца, логировать на каждом этапе основные параметры диагностики (чтобы остледить потом, на каком этапе она отвалилась) и выдавать результат, успешно пройдена диагностика или нет. Реализовал через Playwright и уже через него это позволило избавиться от человеческого фактора что-то упустить и сократить время на тестирование.

Рефакторинг👷 - в моем случае был код, который правился часто и каждый раз нужно было проверять, а не используется ли он для других кейсов, и каждый раз ты боишься что-то сломать, натягиваешь какие-то костыли, чтобы только ничего не поломать, спойлер: для других кейсов он не используется и по итогу это усложняет поддержку кода и может привести к багам в проде. Тут нужно делать конечно все аккуратно и умело, чтобы не удалить что-то важное.

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

Ну вот как-то так, вроде все упомянул, что применял в практике. Буду рад, если поделитесь своими наблюдениями🙂