Мы все совершаем ошибки. Это самый эффективный способ учиться, расти и накапливать опыт. Работа над ошибками помогает совершенствоваться.
Большинство людей не анализирует своих ошибок. Они винят себя за них. И делают это лучше любого строгого начальника.
По моим наблюдениям, пять ошибок, упомянутых в этой статье, свойственны большинству бэкенд-разработчиков. Впрочем, когда речь заходит о ошибках, профессиональная сфера не имеет значения. Мы все подвержены им в равной степени.
Ошибка #1: технический долг
Вам наверняка приходилось сталкиваться с невыполненными работами по проекту. Как правило, их авторы сосредотачиваются на технических аспектах приложения, мало заботясь о том, как оно будет использоваться. Такие разработчики оставляют множество недоработок в коде. Если бы они следовали технологическим требованиям, значительно сократили бы усилия и затраты, необходимые для поддержки их проектов.
Обычно подобной халатностью страдают начинающие разработчики. Они не знают эффективных для пользовательского опыта технологий, снижающих техническую нагрузку. В результате их приложения работают медленно, требуя значительных усилий по техподдержке и обработке.
Начинающие разработчики, как и новички-аматоры, склонны чрезмерно усложнять рабочий процесс. Между тем, опытные мастера сокращают усилия и затраты, используя меньшее количество технологий, чтобы сэкономить время обработки и улучшить пользовательский опыт.
Кроме того, технический долг часто указывает на нечитаемый код. Первое правило разработки — передать в проекте логику, понятную другим разработчикам. Это достигается путем применения общепринятых методик и стандартов оформления кода или следования формату CamelCase при записи переменных.
Тщеславные новички стараются использовать все возможное. Впоследствии их решения оборачиваются головной болью для пользователей, имеющих дело с зависающими от перегрузок приложениями. Опытным разработчикам приходится заниматься рефакторингом кода, что, по сути, является пустой тратой времени. Ведь с увеличением объема кода возрастают требования к тестированию и вероятность появления ошибок. Чем меньше кода, тем лучше.
Избежать этой ошибки можно, избавившись от тщеславия и выбирая только необходимые технологии, соответствующие лучшим практикам и отраслевым стандартам. Я грешил техническими долгами на начальном этапе освоения фронтенд-фреймворков и библиотек. Это приводило к увеличению количества кода, ошибкам и огромным затратам на рефакторинг. Следуйте стандартам DRY, KISS и YAGNI.
Ошибка #2: приверженность одной технологии
Допустим, вы потратили деньги на изучение React на Udemy. Значит ли это, что вы должны создавать все приложения с помощью React? Нет. Не используйте одни и те же технологии, библиотеки или фреймворки для каждой задачи. Выбор инструментария зависит от проблемы, которую вы решаете.
React + Vite может подойти для разработки промежуточных веб-приложений. Однако этот набор инструментов не годится для создания приложений, ориентированных на производительность. В таком случае стоит перейти на SolidJS, NextJS или любой другой фреймворк, предназначенный для создания программных продуктов с высокой производительностью.
Исходя из поставленной задачи, меняйте используемые технологии. Сохраняйте базовые навыки в выбранном языке (например, JavaScript) и продолжайте осваивать новые технологии.
Приверженность одной технологии может затруднить освоение пользователем вашего приложения. Для устранения проблем, с которым оно неизбежно столкнется, все равно придется менять технологию. Не лучше ли сделать это в самом начале?
Ошибка # 3: незащищенность от SQL-инъекций
У злоумышленников достаточно методов, чтобы взломать базу данных и похитить учетные данные. Наиболее распространенный из них — SQL-инъекции. Однако несмотря на распространенность этого метода находятся те, кто становится его жертвами.
Дело в том, что только высококвалифицированный разработчик способен написать код, который не позволяет внедрять запросы, изменяющие базу данных. Новички же не владеют тонкостями работы в этой области.
По данным на 2022 год, на долю атак SQL-инъекций приходится 33% от общего числа уязвимостей, возникающих в веб-приложениях. Конкатенируя нежелательные строки со стандартными запросами, хакеры получают доступ к базе данных и, как правило, запускают DML-команды (data manipulation language — язык манипуляции данными).
Избежать этой ошибки можно, передавая в запросах необходимые параметры с конкретными, а не общими значениями. Не создавайте стандартные запросы для каждой операции, чтобы облегчить себе работу. Это может привести к форс-мажору. Используйте несколько баз данных и не собирайте все фрукты в одну корзину.
Диверсификация — вот ключ к успеху. Проводите анализ кода. Проверяйте каждую строку, особенно конкатенированную, при выполнении запросов. Постоянно делайте резервные копии производственных баз данных.
Ошибка # 4: излишняя сложность дизайна
Вы тот, кто пренебрегает удобством использования приложения в угоду эстетике? Это типичная “болезнь” новичков. Они обычно переусложняют дизайн, уделяя недостаточно внимания качеству взаимодействия пользователя с приложением. Графический интерфейс может впечатлять, но только до этапа тестирования.
Приложения со множеством “наворотов” теряют свою ценность, как только попадают в руки пользователей, потому что 95% из них не могут ими воспользоваться. Виной тому излишняя сложность. Пользователи ценят простой дизайн. Им нужны интерфейсы, которые они уже видели раньше. Они любят привычное, чтобы тратить меньше усилий на выполнение любой задачи.
Люди откажутся от приложения, если вы заставите их изучать новые принципы использования. Им удобнее иметь дело с механизмами, разработанными предыдущими поколениями дизайнеров. Молодые люди могут менять свои привычки. Большинство пользователей — нет.
Проектируйте и создавайте продукты для массового потребителя. Разрабатывайте интерфейсы с применением известных стандартов и моделей пользовательского поведения. Предоставьте людям возможность использовать продукт с минимальными усилиями. Социальные сети создали решение, позволяющее избежать этой ошибки. Не зря они вызывают привыкание. Меньше усилий — больше вознаграждение.
Ошибка # 5: выбор немасштабируемых технологий
Допустим, вы разработали решение и написали код. На данный момент вас все устраивает, а в дальнейшем? Потребуется вносить изменения, верно? Нет. Подумайте о масштабируемости с нуля. Количество рефакторингов, как и время отладки, необходимое для исправления багов и сбоев, не бесконечно.
С самого начала выбирайте технологии, решающие конкретные проблемы, и масштабируемые с учетом возможных будущих показателей. Например, подумайте, можно ли использовать React для решения специфических задач в будущем при диверсификации? Если нет, то разумнее выбрать другую технологию.
Большинство бэкенд-разработчиков применяют один и тот же набор технологий для решения любой задачи. Они не задумываются о возможном трафике и транзакциях данных, которые могут возникнуть в будущем. В 2013 году хакеры воспользовались плохо масштабируемой кодовой базой Snapchat и получили доступ к данным миллионов пользователей. Вы же не хотите, чтобы подобное произошло с вашим продуктом?
Выбирайте технологии, которые масштабируются. Постоянно оптимизируйте код. Сократите время и стоимость будущей разработки.
Читайте также:
- Раскрываем силу JavaScript: сокращение размера пакета NPM на 99%
- Волшебство веб-разработки: создаем цифровую страну чудес
- Современная фронтенд-разработка: мир HTML, CSS, JavaScript и популярных фреймворков
Читайте нас в Telegram, VK и Дзен
Перевод статьи Afan Khan: Avoid These 5 Mistakes as a Web Developer
