Типичные ошибки при создании Frontend приложений

Хабр, привет!

Мы — команда платформы интеллектуального управления контентом и цифровизации бизнес-процессов СИМФОНИЯ (ЕСМ/CSP/BPM) от ITFB Group. Сегодня решили поговорить об общих принципах, процессах и подходах, которых мы придерживались при создании нашей собственной платформы. Никакого кода, но и водой топить не будем! Поэтому, предлагаем сразу начать.

Не важно как, сделай так, чтобы работало!

Как и любой текст, который попадает к редактору журнала, код должен иметь четкую структуру, соответствовать установленным стандартам и лучшим практикам. Это важно, ведь код также читают и анализируют люди.

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

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

Давайте решать проблемы по мере их поступления!

Любое программное обеспечение нуждается в тщательном проектировании и архитектурном планировании с самого начала. Это помогает избежать проблем и ускорить разработку в дальнейшем.

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

«Зачем нам дизайн?! Я и так всё расскажу»

Возможно расскажите, но увидев результат не решите ли поменять, добавить или убрать что-то в проекте?! Проблема заключается в том, код требует более глубокой проработки, тестирования и рефакторинга, в то время как изменения в дизайне могут быть относительно быстрыми.

Специалист не всегда может предусмотреть все возможные сценарии и требования, которые могут возникнуть в процессе разработки. И не стоит забывать, что в Figma можно копировать стили прямо в код, что тоже упрощает разработку.

«Там же другой цвет по дизайну… и где скругление?!»

Если крупный проект заранее понимает, что дизайна будет много, то использование дизайн-системы с интеграцией Figma через API является очень эффективным подходом для крупных, динамичных проектов, где гибкость и оперативность в работе с дизайном имеют большое значение.

«Слышал про эту методологию?! Давай внедрим!»

Инновации — хорошо, даже чудесно, но не стоит с этим спешить. Например, некоторые методологии могут сильно усложнить небольшие проекты и только растянуть сроки их реализации. Поэтому, сперва нужно чётко понимать необходимость интересуемой технологии и какой профит получит бизнес?!

«Нет! Нам не нужна доступность»

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

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

«Кому мы нужны?! Безопасностью займемся потом»

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

Чтобы избежать подобных проблем, необходимо пересмотреть систему доступа к облачной платформе. Следует четко разграничить права пользователей: только авторизованные разработчики должны иметь возможность загружать и удалять данные, а остальные сотрудники — только просматривать информацию.

Или думаете SQL-инъекции это редкость? SQL-инъекции — это серьезная проблема, с которой сталкивается современный российский бизнес. Даже начинающий хакер может получить доступ к вашей базе данных и полностью ее очистить, просто вставив несложный код в форму авторизации на вашем сайте. Поэтому необходимо уделять пристальное внимание вопросам безопасности вашего проекта.

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

«Производительность меня сейчас не интересует!»

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

«Сперва разработаем Backend, потом займёмся Frontend…»

Когда backend- и  frontend-разработчики работают независимо друг от друга, это приводит к большому количеству последующих правок. Отсутствие синергии между ними вынуждает frontend-разработчиков подстраиваться под уже заданные реалии, что негативно сказывается на производительности проекта и может вызвать раздувание API.

Более эффективным подходом будет заранее найти компромисс по структуре данных, необходимым методам и другим ключевым аспектам. Это позволит избежать проблем, связанных с несогласованностью действий команд backend- и frontend-разработки.

«Жесткая типизация?! Мне кажется это усложнение…»

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

Недавно, 19 июля 2024 года, произошел массовый сбой в истории, когда из строя вышли около 8,5 миллионов Windows-компьютеров с ПО CrowdStrike. Причиной стало несоответствие между ожидаемым и фактическим количеством входных параметров.

Поэтому наш совет: типизируйте свой проект, внедряйте TypeScript, чтобы обеспечить надежность и предсказуемость работы системы.