Про важность фронтенда для бизнеса и про зону ответственности ⭐️

1. SEO- зона ответственности фронта. Поисковые роботы будут позволять вашему веб-приложению занимать более высокие позиции в результатах поиска браузера. Это увеличивает посещаемость ресурса и продажи на нём.

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

3. Чем выше скорость загрузки, тем вероятнее, что клиент выберет ваш сервис. Фронтенд разработчик с помощью своих умений в оптимизации решает этот вопрос.

4.❗️ Самое важное:
При грамотно подобранной архитектуре, при написанных на функционал тестах, да и вообще при использовании правильных инструметов бизнес легко масштабировать.
Новые правки не ломают старый функционал, да и доходят до пользовател они быстро. Легко добавим возможность покупки товара в приложении, авторизации или заполнение иных форм, если использованы грамотно подобранные инструменты.

1. Узнаваемый и приятный UX/UI радует посетителей. Всё интуитивно понятно, плавно и качественно. К приложению хочется возвращаться и рекомендовать другим.
   В этот же пункт я бы отнесла поддержку на разных устройствах и в разных браузерах. Хочется открывать и с телефона, и с компьютера, и с планшета

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

AudioEye

WCAG Website Accessibility | AudioEye

Combining real-time monitoring and automation with expert services allows you to unlock the full potential of ADA & WCAG compliance to mitigate legal risks.

Комментарии ?

Раньше даже бы не подумала, что комментарии в коде- такая тема, про которую нужно поглубже подумать и что-то почитать. Пока не подумала и не почитала))

Ключевые моменты:

1) Комментарии не уменьшают когнитивную сложность написанной функции ?.
Раньше я писала к трудночитаемым алгоритмам в функции комментарии и думала, что я молодец) Хотя для программиста гораздо понятнее прочесть легкий и понятный код, нежели сложный комментарий и сложный код.

Его не только тяжко читать, но и сложно масштабировать. Лучше потратить время на рефакторинг функции и убрать комментарий.

2) Не стоит делить функцию на логические блоки с помощью комментариев. Лучше её просто деструктуризировать.?

3) Комментарии сильно влияют на чистоту кода ?.
Есть мнение, что иногда они просто излишни. Зачем в проекте обязательный JSDoc и комментирование входных параметров, значение которые очевидны по неймингу? Но, как мне кажется, это не мешает и придает стандартизизацию подходу. Тем более, что существует JSDoc 3, который генерит документацию на основе комментариев ?

4) Комментариями хорошо объяснять оригинальные бизнес-решения заказчика ??

5) Комментами описываются Юридические моменты, которые важно знать ?️. Локальное использование, но мне приходилось иметь с таким дело

6) Использование @sumary и TODO.При интеграции с внешними API, все запросы и ответы лучше покрывать @summary для расшифровки, а то не все внешние сервисы имеют понятные контракты взаимодействия. Ну и TODO для будущих доработок.

7) Удаляем ненужный код, а не комментируем его.Сприходом гита в нашу разработку никакие изменения не будут забыты навсегда.

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

Более подробную инфу об этом можно почитать в документации и у Роберта Мартина в «Чистый код» ?

Я уволилась….

Тяжко уходить, особенно, когда ты сентиментальный, а команда была классная и тебя очень тепло провожает ?

Но, как бы ни было печально уходить, всё же приезжать и работать из любой точки мира (особенно, Казахстана) мне приоритетнее ?‍?‍?‍?, а уже отпуска планировать чисто для отдыха в каком-то новом месте. Я выбрала новую компанию, в основном, по этому критерию. Но есть и ещё…

В смене компании много плюсов:

?‍♀️Приобретаешь коммерческий опыт в разных технологиях. Твой стек расширяется и углубляется в разы быстрее. Из этого вытекает рост хард скилов

?‍♂️Растешь в разы в зарплате. Оставаясь на одной работе, не вырасти за раз на 100% и более. Переход в другую компанию это позволяет (актуально для it-рынка)

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

?‍♀️Погружаешься в новую проф. сферу. В итоге, за несколько лет разбираешься в документообороте, строитетельстве, недвижимости, транспорте и т.п. Это плюс, скорее, для общего развития))

Если вам актуально, то у вас обязательно получится организовать такой переход. Главное, постараться быть лучшим из всех кандидатов. Смотрите собеседования, ищите поддержку и помощь близких, закрывайте пробелы в знаниях и всё будет хорошо!
А меня завтра ждёт последний рабочий день в нынешней компании ?

Безопасность 1.1?
А вот и ещё предосторожности и потенциально проблемные места ?. Как раз их мне и приходится фиксить чаще всего:

2) Правильная обработка токенов авторизации ?. Нужно подумать о следующем:
— Хранение в системе (НЕ в LocalStorage, лучше в coockie)
— Шифрование токена
— Ограничение срока действия токена и регулярное его обновление
— Мониторинг и журналирование: Ведите журнал действий с токенами, чтобы быстро обнаруживать подозрительную активность и реагировать на нее

3) Правильная настройка CORS. Тут нужно убедиться, что:
— Сервер, с которого запрашиваются данные или ресурсы, правильно настроен для обработки CORS
— Использованы безопасные методы запросов
— Разрешены только безопасные источники
— В случае возникновения проблем с CORS, обрабатываются ошибки соответствующим образом, чтобы предотвратить утечку конфиденциальной информации (об этом ниже)

4) Шифровать все данные ?. В базах данных не должен хранится обычный текст, если данные конфиденциальны (а это буквально все данные о пользователе)

5) Не предоставлять слишком много информации об ошибке ❌. Это может дать представление о том, как написан наш код. Лучше делать кастомные заглушки на разные ошибки

6) Вовремя обновлять библиотеки, которые используете. Внутри ваши зависимости частенько тянут другие, поэтому порой случается так, что вы, например, обновили ramda, видите в "dependencies" актуальную версию, но в package-lock можно заметить, что существуют зависимости, которые тянут ramda более старой версии, которая уже не так безопасна. Поэтому, нужно обновить и родительскую библиотеку

Безопасность ?
Реакт подвержен различным атакам, которые лучше предотвратить, а то бизнесу будет очень очень плохо((
Сначала расскажу об одной атаке, а в следующей части про остальные проблемные места веб-приложений, которые мне частенько приходиться фиксить:
1) Межсайтовый скриптинг или XSS?- тип уязвимости, когда злоумышленник может внедрить свой код на наш сайт. Это редкая ситуация, т.к. обычно с помощью Реакта мы не редактируем напрямую внутренний HTML код. Но если мы это будем делать, то нужно принять меры, чтоб это обойти.

Меры предосторожности ?:
— Использовать функцию dangerouslySetInnerHTML (заболтивое предупреждение о безопасности находится прямо в имени) только в крайне необходимых случаях и всегда очищать и валидировать входные данные.

— Использовать библиотеки для защиты от XSS атак, например, DOMPurify. Она очищает входные данные от потенциально вредоносного кода. Или использовать npm-модуль serialize\-javascript, который предназначен для экранирования выводимого JSON.

— Использовать JSX для вставки динамических данных в шаблоны, так как он автоматически экранирует специальные символы, предотвращая XSS атаки.

— Следить за обновлением самой библиотеки React принимающие переменные, которые могут содержать недоверенные данные в теге script.

пример такой атаки:
Атрибут href в теге <a> содержит URL-адрес ссылки. Этот URL может содержать и JavaScript-код вида javascript: <anything>. Если содержимое ссылок формируется на основе данных, введенных пользователем, то злоумышленник может вставить вредоносный код. Если пользователь перейдет по такой ссылке, браузер выполнит скрипт злоумышленника.
Для предотвращения XSS атак, необходимо настроить ссылки так, чтобы использовать только безопасные протоколы, например, http: или https:. Также необходимо экранировать HTML-сущности в URL-адресах

составила Frontend roadmap ⭐️

Представляет из себя интеллект-карту, которая состоит из тем, в которые нужно быть погруженным (где-то больше, где-то меньше) frontend разработчику (в частности, React-разработчику). Темы, которые требуют большой практики, а некоторые просто знания теории.

? Будет удобна для подготовки к собесам на уровень middle. Найти то, что забыл или не знал. А уровень глубины знаний уже варьируется из компании в компанию.
?А вот для изучения или входа в разработку подойдет тем, кто уже базово знаком с терминами и примерно ориентируется в профессии, понимает с чего начать. Для начального уровня переделаю с формата интеллект-карты в формат схемы, чтоб можно было идти по пунктам.

Всё на основе личного опыта, опыта друзей, коллег и всяких полезных документаций. Будет круто, если найдёте карту полезной ?