Лог (англ. log, дословно переводится как бревно) - это информация о некотором событии, которое произошло в системе.
Логирование (англ. logging) - это написание логов, то есть вывод информации о том, что происходит в системе.
Пример событий в системе: "Сервер запущен", "База данных подключена", "Произошла ошибка", "Пришёл запрос с клиента", "Пользователь авторизировался" и так далее.
Логи могут иметь любую структуру, которую определяет пишущий их человек.
Например, самый примитивный лог предтавляет собой обычный текст
Server is running on PORT: 3000
Более продвинутый лог может содержать время с часовым поясом, имя файла или класса, тип события, текст и так далее
Jan 4, 2022 17:46:27 (UTCMSK) | index.js | SUCCESS | App is running on the port: 8080
Jan 4, 2022 22:00:15 (UTCMSK) | dbContext.js | ERROR | Connection to MongoDB was interrupted!
Логи могут выводиться в консоли, записываться в базу данных или в файл. Поскольку события в системе происходят довольно часто, со временем логов может накопиться слишком много. Поэтому логи наделяют сроком годности (скажем, месяц), а затем удаляют их.
Логером называют сервис, который позволяет записывать логи. Существует множество библиотек логеров, но его также несложно написать самому.
Логирование очень важно, поскольку оно отражает историю событий в системе. Оно позволяет отслеживать любые интерисующие вас действия в системе. И при возникновении ошибки вы всегда можете знать, какое действие предшествовало этой ошибке и в чём ошибка заключалась.
Всегда довольно неприятно, когда в какой-либо программе появляется ошибка, а в консоли пусто или написано что-то вроде ERROR CODE 110050 без всяких пояснений и без возможности найти описание ошибки в интернете. Поэтому давайте писать подробные, отчётливые логи, которые будут понятны и помогут вам или вашему товарищу по проекту быстро найти и исправить проблему.
Аналитика похожа на логирование тем, что работает с событиями, но она имеет немного другую цель.
Логи нацелены на то, чтобы сохранить историю того, что происходило в системе. Аналитика направлена на то, чтобы отследить, какие действия были совершены пользователем.
Логи становятся бесполезными через некоторый, достаточно короткий промежуток времени. Аналитика, наоборот, стремится получить статистику действий пользователей: на какие страницы заходят чаще, какие товары чаще просматриваются и покупаются, какие кнопки больше всего кликаются. Эта статистика позволяет бизнесу понять, что пользователям интереснее всего. На основании этой статистики можно делать рекламу, предложения пользователю.
Если на проекте используется Server Side Rendering (SSR), то аналитика может подсказать, какие страницы стоит загрузить в первую очередь, поскольку велика вероятность, что именно на них пользователь зайдёт скорее всего (а время отклика играет большую роль, когда речь идёт о вебсайтах).
Автоматизированное тестирование подобно лабораторным анализам или техосмотру.
Действительно, врачи советуют в качестве профилактики многих заболеваний ежегодно сдавать некоторые примитивные лабораторные анализы и не менее базовые обследования (анализ крови, УЗИ, флюрография и так далее). Эти анализы и обследования позволяют убедиться, что с вашим организмов сейчас всё в норме.
Водителям необходимо проходить ежегодный техосмотр, который позволяет убедиться, что ничего страшного с техникой за год не произошло и можно смело продолжать на ней ездить.
Чем быстрее вы находите отклонение в вашем организме или неисправность в вашей технике, тем больше шансов, что вы сможете исправить её с малыми затратами.
И далеко не всегда такие вещи можно рассмотреть невооружённым глазом, иногда требуется специальное оборудование, некоторый инструмент.
Когда дело касается приложений, таким инструментом выступают автоматизированные тесты. Они позволяют проверить, соответствует ли приложение всем указанным требованиям на данный момент.
Чем шире покрытие приложения тестами, чем детальнее тесты описывают требования бизнеса, тем больше шансов быстро и безболезненно найти и устранить отклонение в коде.
Когда вы приступаете к написанию тестов, вы начинаете продумывать все возможные варианты (англ. edge cases), исходы, случаи. И на каждый случай пишете отдельный тест. Затем все тесты запускаются последовательно. И те, которые провалились, указывают на проблему.
Это тем более важно, поскольку каждый новый кусочек кода может непредсказуемо повлиять на весь предыдущий код. Чем больше кода написано за всё время, тем больше потенциальных багов и тем больше времени необходимо на поиск бага (дебаг). И чтобы не проверять каждый раз все возможные случаи вручную, достаточно один раз их описать в виде тестов и время от времени их запускать (или настроить автоматический запуск тестов при каждом пуше или деплое).
Следует помнить, что под безопасностью подразумевается не только безопасность приложения, но и безопасность любого пользователя, которому довелось это приложение использовать.
Безопасность (англ. safety) - состояние защищённости кого-либо или чего-либо.
Приложение в безопасности, если злоумышленники не могут подвернуть его взлому.
Приложение безопасно для пользователя, если данные пользователя, который пользуется данным приложением, находятся в безопасности и не могут быть украдены ни создателем сайта, ни злоумышленниками.
Безопасность является довольно обширной темой, которая в каждом приложении раскрывается по-разному, но я постараюсь привести список довольно часто встречающихся моментов.
- Не храните важные данные (пароли, ключи, номера карточек и так далее) в Local Storage.
- Если в системе есть логгирование, следует отключить логирование тех параметров запросов, которые содержат введённые имя пользователя и пароль.
- Не храните ключи, пароли и другие важные данные в константах, в свойстве
scripts. Используйте для этих нуждdotenvили другие библиотеки, работающие с переменными окружения. - Регулярно делайте
npm audit, обновляйте пакеты, в которых были обнаружены уязвимости. - Не сохраняйте пароль пользователя в явном виде в базу данных. Вместо этого сохраняйте хэш, который получается из настоящего пароля и соли при использовании
bcrypt. - Не позволяйте пользователям системы выбирать пароль, состоящий менее, чем из 8 символов латинского алфавита. Такие пароли будет сложнее подобрать.
- Для аутентификации/авторизации старайтесь использовать сторонние сервисы (например, Auth0, Google Sign-In, Github и другие). При соблюдении требуемых этими сервисами условий вы можете быть уверены, что ваши пользователи находятся в безопасности.
- Используйте протокол HTTPS вместо HTTP, если сайт находится в публичном доступе (доступен не через localhost). HTTPS шифрует данные тела запроса, что не позволяет злоумышленникам перехватить ценную информацию.
- Не используйте формат
md5для шифрования каких-либо важных данных. Этот формат можно с лёгкостью перевести в обычный текст, не имея при этом никакого ключа. Для этого существует множество сервисов в интернете. - Не используйте примитивные пароли для админки приложения (по типу
admin - admin,admin - qwerty12345789,username - password) - По возможности используйте двухфакторную аутентификацию. Так, если злоумышленник украдёт или подберёт ваш пароль, он всё равно не сможет войти без телефона, который будет всегда при вас.