План:

1) Введение

2) Технический долг

4) Решение ранее описанных проблем

5) Выводы

Введение

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

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

Технический долг

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

С момента начала написания блога и по сей день в нем были следующие недоработки:

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

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

Давайте разберем самые интересные. Одной из таковых проблем мне показалась замена текстового редактора, найти сам редактор оказалось не проблемой. Также для меня было открытием, что новый редактор и ему подобные хорошо работают с html кодом. Здесь для меня оказалась проблема работы с картинками и как работать с ними.

Изначально мною было принято неправильное решение — хранить картинки в базе данных в basе64. Как показала практика — это было не лучшее решение. При загрузке сайта картинки долго загружались, потому что были в коде html страницы. Проблема выражалась в следующем, у меня есть два блока на главной странице и блок с картинками, которые были превью для блога. Они были закодированы в base64 и возвращались в этой же кодировке, что привело к вышеописанной проблеме. Исправить этот недостаток получилось путем генерации картинки во время запроса данных и отправке ее на сторону клиента. Таким образом получилось решить проблему загрузки в трех главных блоках, но это была не вся проблема.

При использовании трансформации файла в формат base64 используется больше ресурсов. В результате этих манипуляций размер файла становится больше на 33-36% больше исходника. В этом случае лучше использовать нативные средства формы. В буквальном смысле нет никаких преимуществ в использовании данных в кодировке base64; эта опция предусмотрена только для большей совместимости с системами, которые не поддерживают загрузку двоичных файлов. Лучше хранить данные «сырыми» и обращаться к ним таким образом во всех местах, преобразовывая их по требованию, когда в этом есть необходимость.

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

Еще одной интересной была проблема с переводами. Эту проблему я ранее описывал в другой статье. Тогда я четко для себя решил оставлю сайт с одним урлом, но с двумя языками. И вот когда недавно решал проблемы с оптимизацией на сайте, то мне в рекомендациях в документации было предложено сделать статический сайт. Сначала, когда сделал генерацию статических страниц — все работало хорошо, до момента пока на сайте не будет сменен язык и перезагружена страница. Долго не мог понять из-за чего это происходит в боевом режиме. Вот здесь я полез уже читать документацию, чтобы понять процесс более глубже. Оказывается, что nextjs у себя в документации описывал именно локализацию, а не мультиязычность, это же я объяснял в своей первой статье. Сопоставив документацию и мои размышления из первой статьи я понял, что сделать два перевода для одного адреса в рамках статической страницы не получится.

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

Выводы

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

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