Разработчики полного стека - это мечта для гибкой команды, но многим не хватает знаний о базах данных. Стив Хопкинсон, менеджер по технологиям Publicis Sapient, исследует, как выглядит дефицит базы данных и как вы можете избежать этого в своей команде.

Теоретически разработчики полного стека - идеальный гибкий ресурс. Независимо от того, смещена ли текущая фаза разработки в сторону передней или задней части, они могут сместить фокус, чтобы соответствовать требованиям проекта, гарантируя, что ресурсы никогда не будут недоиспользованы или узкими местами.

На самом деле у всех разработчиков full-stack есть слабое место. Для многих это слабое место - база данных. Если у вас есть команда разработчиков полного стека, которые имеют одно и то же слабое место, влияние на программное обеспечение - и на производительность команды - усиливается.

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

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

Следующий сценарий, взятый из реальных примеров, помогает объяснить:

Как выглядит дефицит навыков работы с базами данных?

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

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

«Мы не такие».

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

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

Покопавшись в репозитории, вы найдете каталог под названием «migrations», заполненный SQL-запросами, написанными неизвестным разработчиком. Он не обновлялся несколько месяцев. Когда ваша работа в четвертый раз за неделю сорвана из-за проблем с базой данных, вы начинаете подозревать, почему они покинули проект.

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

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

Google Trends, надежный индикатор изменения интереса с течением времени, показывает, что количество запросов« база данных упало на 80%» с тех пор, как Google начал сбор данных в 2004 году. Как мы к этому пришли? Как это влияет на команды? И что мы можем с этим поделать?

Полный стек? Не совсем…

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

Всплеск популярности термина «разработчик полного стека» совпадает с первым крупным выпуском Node.js. Возможность писать JavaScript как на клиенте, так и на сервере стала огромным стимулом для текущего поколения разработчиков полного стека. Но языковой барьер между сервером и базой данных остается, а концептуальные барьеры еще больше.

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

После преподавания как Node.js, так и PostgreSQL на ведущем учебном семинаре по веб-разработке, разница в реакциях студентов на них была поразительной. Группы, которые активно обсуждают шаблоны проектирования серверов, тускнеют при первом упоминании базы данных.

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

Симптомы дефицита навыков работы с базами данных

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

С другой стороны, схемы SQL, заполненные строками JSON и таблицами "ключ-значение", часто являются признаком того, что документно-ориентированная база данных была бы лучшим вариантом. В каждом случае приложение требует двойной стоимости - во-первых, при реализации шаблона, который противоречит дизайну базовой системы управления базой данных, а во-вторых, в наследовании компромиссов, которые система сделала для реализации задуманного дизайна в первую очередь. .

Страдают и другие навыки. Моделирование данных, традиционно являющееся прерогативой разработчика баз данных, теперь является ключевой компетенцией всего стека - независимо от того, создаете ли вы Redux-магазины или пишете модели в Mongoose. Эти навыки можно развить вне работы с базами данных. Но опыт реализации и поддержки схем подчеркивает ценность фундаментальных принципов проектирования, таких как предотвращение избыточности, соблюдение ограничений и нормализация данных.

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

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

От Active Record до Sequelize, многие инструменты объектно-реляционного сопоставления (ORM) имеют встроенную поддержку для записи и выполнения миграций. Если у вас нет, то существует ряд решений, не зависящих от фреймворка, таких как Flyway от Boxfuse или Phinx, управляемый PHP. Несмотря на это, некоторые команды не следуют тому, что должно быть отраслевым стандартом, что имеет самые разные последствия для их разработки и развертывания.

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

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

Что делать, если вашей команде не хватает навыков работы с базами данных

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

Если ваше приложение работает и ваша команда разработчиков уже на месте, решение двоякое. Убедитесь, что команда приобретает навыки для предотвращения повторения проблем и решения любых существующих проблем.

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

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

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

Заключение

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

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