И если вы когда-нибудь захотите переделать или расширить его, вы можете в конечном итоге потратить время и ресурсы на починку фундамента, прежде чем можно будет выполнить какую-либо работу.
Проницательный читатель уже понял, что я говорю не о недвижимости, а о сходстве между строительством дома и разработкой приложений. В то время как пользователи могут взаимодействовать с внешним интерфейсом приложения, на самом деле back-end делает тяжелую работу. Вот почему важно сотрудничество с лучшими back-end инженерами.
Конечно, чтобы стать хорошим back-end разработчиком, нужно многое. Недостаточно хорошо владеть фреймворком, чтобы удовлетворить потребности современных рынков, претендент на бэкэнд программиста должен уметь хотя бы хорошо владеть следующим списком знаний:
- Структуры данных и алгоритмы
- Базы данных и модели данных
- Несколько фреймворков (и соответствующих языков программирования, на которых они основаны)
- Облачный хостинг (AWS, Google Cloud или Azure)
- Архитектура сервера
- Докеры
Кроме того, им приходится работать под давлением, чтобы уложиться в сроки, а также рефакторинг, отладку или масштабирование на лету. Вот некоторые из наиболее распространенных грехов, совершаемых разработчиками серверной части, могут иметь долгосрочные последствия.
Давайте рассмотрим 6 грехов, которые не должны совершать Back-end разработчики
1. Вы не должны накапливать слишком много технического долга
Первый грех общий как для back-end, так и для front-end разработчиков: наличие значительного технического долга. Agile-команды действительно полагаются на технический долг, чтобы предоставлять более быстрые решения и предоставлять более качественные продукты, но есть вероятность, что чем больше вы накопите, тем выше вероятность того, что в дальнейшем будет труднее внедрить новые решения или масштабировать проект.
Главный принцип здесь - не создавайте код поверх плохого кода, так как после рефакторинга новый код, вероятно, сломается. Лапша-код, длинные функции / методы, слишком много отступов, чрезмерное количество операторов if / else и неправильные методы именования переменных могут показаться мелкими деталями с незначительными последствиями, но они могут создать массу проблем.
Благодаря хорошей практике кодирования и хорошему планированию технического долга можно избежать, и в тех случаях, когда это необходимо, хороший протокол для его отслеживания будет иметь большое значение, чтобы помешать команде построить гору на вершине карточного домика.
2. Вы не должны писать плохую документацию
Хорошая документация похожа на хорошо нарисованную карту или хороший рецепт: она ничего не оставляет воображению. Чтобы взять страницу из дзена Python, явное лучше, чем неявное . В этом смысле один из величайших грехов для back-end разработчиков - думать о документации как о запоздалой мысли. Плохая или отсутствующая документация в лучшем случае приведет к путанице или полностью остановит проект, поскольку разработчикам придется вручную проверять код построчно, чтобы понять, что происходит.
При наличии хороших практик документации фронтенд разработчикам будет легче понять, как их сторона проекта будет взаимодействовать с бэкэндом, а у тех, кто придет после, будет надежный источник информации, к которому можно прибегать при поиске ошибок или при реструктуризации.
В качестве бонуса мы можем добавить еще одну заповедь: вы должны комментировать свой код . Как и чистая документация, закомментированный код поможет рецензентам кода и другим разработчикам понять лежащую в основе логику. Эти комментарии могут даже помочь самим разработчикам, когда они вернутся, чтобы просмотреть код, к которому они давно не прикасались.
3. Вы не пропускаете тесты
Тесты - неотъемлемая часть любого цикла разработки. Написание тестов и стремление к крайним случаям помогает разработчикам серверной части выявлять ошибки и исследовать сценарии, которые в противном случае могли бы остаться незамеченными, пока не стало слишком поздно. Тем не менее, некоторые разработчики предпочитают пропускать некоторые тесты, возможно, потому, что хотят уложиться в сжатые сроки или из-за своей самоуверенности. Таким образом, этот грех часто случается, когда у разработчиков не хватает времени или когда они слишком полагаются на собственное суждение / анализ кода. Ни один набор глаз не обладает достаточным опытом, чтобы предсказать поведение кода во всех возможных ситуациях.
Простой способ избежать этой проблемы - написать тесты вместе с кодом или поделиться псевдокодом с другим разработчиком и попросить их написать набор тестов. Фактически, некоторые команды доходят до того, что сначала создают максимально экстремальные тесты, а затем пишут код. Таким образом, они эффективно развиваются для решения крайних случаев. Тесты - это надежный способ убедиться, что код работает так, как задумано, и что лежащая в его основе логика достаточно гибкая, чтобы адаптироваться и масштабироваться в соответствии с требованиями проекта.
4. Вы не должны использовать несколько технологий для одного и того же решения
Одним из главных достоинств работы с популярными языками программирования, такими как Python или node.js, является количество доступных ресурсов. Итак, зачем писать что-то с нуля, если это можно просто импортировать?
Но это открывает дверь к собственному набору проблем. Слишком большая зависимость от внешнего программного обеспечения и библиотек означает, в первую очередь, что вы имеете дело с несколькими API одновременно, а это уже само по себе является проблемой.
Но, помимо этого, технологии постоянно обновляются, что может привести к непреднамеренным изменениям или ошибкам, которые могут нарушить ваш собственный проект. Кроме того, проекты устаревают, и эта замечательная библиотека, которую вы нашли, может внезапно исчезнуть в мгновение ока.
Это не значит, что нужно придерживаться одного решения, скорее это слово предостережения о том, что внедрение новых технологий в проект всегда должно быть хорошо продуманным решением, и что иногда преодоление лишнего километра, чтобы сделать это самостоятельно, избавит от головной боли.
5. Вы не должны забывать протокол резервного копирования
Практически каждому back-end разработчику приходится иметь дело с базами данных в своей карьере, и, как мы все знаем, если приложение - это тело, то данные - это кровь, которая дает ему жизнь. Хорошие бэкэнд-разработчики хранят обширные резервные копии своих данных в облаке, на физических носителях, на удаленных серверах и почти везде. Без них инженеры рискуют потерять всю свою работу из-за поломки оборудования или программного обеспечения. Вот почему резервное копирование должно быть частым и надежным. Если ваши данные обновляются поминутно, потеря пары дней может стать катастрофой для проекта. Лучше вложиться в решение для хранения, чем потерять все из-за одной ошибки.
6. У вас не должно быть плохого планирования перед построением модели данных
Восстановление модели с нуля может быть кошмаром, поэтому правильное построение модели с первого раза сэкономит время и инвестиции. Иногда реструктуризация моделей данных неизбежна, но пусть эти времена будут результатом внешнего влияния, а не недостатка предвидения.
Хорошие бэкэнд разработчики получают очень четкое представление о том, что должен делать проект, и разработают модель, которая соответствует проекту с учетом масштабируемости, даже если проект не предполагает масштабирования в ближайшее время. Разработка хорошей модели данных - отличный пример долгосрочного планирования, который позволит избежать проблем, связанных с базами данных, которые чрезмерно расширяют свои возможности.
Хороший back-end разработчик - стратег и командный игрок Технические навыки - не единственное, в чем должен быть хорош back-end разработчик. Что действительно делает эксперта блистательным, так это то, что он понимает свою роль в команде разработчиков и насколько проект зависит от их работы. Наем хорошего back-end разработчика может быть разницей между домом, который выдерживает ураган, и домом, который разваливается в ветреную пору.