Инфраструктура окружает нас повсюду, и мы потребляем доступные функции, не замечая их как таковых. Не только в цифровом мире, но и в реальном мире.
Различные инфраструктурные шаблоны (функции), объединенные вместе, создают систему. Важно, чтобы эти шаблоны были предсказуемыми и последовательными.
Давайте посмотрим на транспорт. В нашем современном обществе есть поезда, автобусы, самолеты, корабли и т. д. Большинство из нас хоть раз в жизни пользовались автобусом, и мы точно знали, что он делает и когда.
Такое предсказуемое поведение позволяет нам развивать интуицию. Интуиция — очень важная часть нашей повседневной жизни, и разработчики не избавлены от нее.
Впервые я услышал об интуиции в контексте программирования, когда работал в Shoutem. Над этим проектом работала действительно необычная группа инженеров.
Затем веб-руководитель сказал мне в спонтанном разговоре, что наш код должен быть более интуитивным. Эта часть информации застряла у меня в голове до сегодняшнего дня, как квест, который я должен выполнить. Как написать более интуитивно понятный код?
Я пытался попасть туда еще до этого разговора, даже не осознавая этого, но только после этого момента я получил осязаемую вещь, которую я мог подтвердить в более широкой картине. Является ли этот новый фрагмент кода интуитивно понятным?
Интуитивно понятный код охватывает множество вещей одним словом, например:
- Есть ли в кодовой базе уже установленный шаблон для проблемы?
- Соответствует ли новый код установленным шаблонам?
Он не подтверждает качество установленных шаблонов, он проверяет предсказуемость. В групповых проектах предсказуемость важнее качества кода как такового.
Написание интуитивно понятного кода
Прежде чем мы перейдем к самому коду, нам нужно вернуться на шаг назад, к инфраструктуре.
Когда у нас есть проблема, мы сначала должны увидеть все доступные шаблоны, предоставляемые инфраструктурой, которые можно использовать, распознать, какой из них подходит для нашей проблемы, и только после этого начать писать код. Например, мне нужен новый сервис, промежуточное ПО, контроллер и т. д.
Как правило, менее опытные разработчики сразу же начинают работать над проблемой, не принимая во внимание то, что уже существует на концептуальном уровне, что может быть реализовано.
Хорошей аналогией было бы, если бы вам пришлось отправиться в город и вместо того, чтобы сначала искать доступные варианты, просто импульсивно выйти за дверь и искать решение на ходу.
К настоящему времени вы, возможно, уже поняли, что фреймворки обычно предоставляют инфраструктуру. При правильном использовании фреймворки определяют, как решаются определенные проблемы, не заботясь о деталях реализации, и это помогает в создании интуитивного представления о проекте.
Итак, фреймворк = хорошо, однако, поскольку мы принимаем эти вещи как должное, обычно только разработчики, работающие над фреймворками, тратят достаточно времени на размышления об инфраструктуре. Средний разработчик не развивает правильный мыслительный процесс, который может помочь ему жить интуитивной жизнью вне рамок.
Другими словами, особенно в мире JavaScript, разработчики слишком много внимания уделяют решению проблемы, а не более широкой картине, инфраструктуре.
Что такое инфраструктура
Можно смешать абстракцию реализации с инфраструктурой. Инфраструктура не вдается в детали реализации, она просто определяет шаблоны на концептуальной основе.
Хорошим примером инфраструктурного шаблона в современном веб-мире является компонент. Всем известно, что если проблема требует какого-то пользовательского интерфейса и, возможно, немного логики, компонент является шаблоном для нее.
Теперь мы можем быть немного умнее и сделать вещи более конкретными. Вместо того, чтобы иметь компоненты в виде единого инфраструктурного шаблона, мы можем определить несколько категорий, таких как страница, компонент пользовательского интерфейса (он же глупый) и компоненты (он же умный).
Благодаря этим трем инфраструктурным шаблонам наш код автоматически становится более читабельным и предсказуемым, более интуитивным.
Представьте, что у вас есть ошибка на определенной странице. Возможно, вам просто пришла в голову какая-то папка, куда вы бы посмотрели в первую очередь. Это интуиция!?
Примеры
Инфраструктура влияет на все аспекты проекта, а не только на технические.
Тесты
На уровне инфраструктуры проект должен иметь тестируемую среду. В мире React это означает установку библиотек, связанных с тестированием dom, моментальных снимков и т. д., чтобы, когда придет время и нужно протестировать компонент, можно было написать тест.
Многие из этих проблем уже решены с помощью CRA, но это не менее важная часть инфраструктуры.
Детские площадки
Это один из моих любимых. Сборник рассказов является примером детской площадки. Вы слышали о термине «детская площадка»? Отличный инфраструктурный пример. Это среда в проекте, в которой системный компонент может быть запущен без запуска всей системы.
Он отлично подходит для разработки компонентов пользовательского интерфейса. Цель этого состоит в том, чтобы получить гораздо более быстрые циклы разработки.
Маршрутизатор
Этот идет с обеих сторон. Перед запуском практически любого веб-проекта одним из первых действий является установка маршрутизатора и тестирование маршрута. Это хороший пример своевременно подготовленной и протестированной инфраструктуры.
Это также показывает, что инфраструктура не заботится о деталях реализации, ей просто нужно предоставить шаблон для общей проблемы.
Услуги
Теперь немного конкретнее для меня. В моем мире сервисы представляют собой функции, которые модифицируют модели, по сути, сервисы знают структуру модели и бизнес-логику.
Это помогает мне распределять функции по категориям, чтобы ничто не попало в печально известные утилиты или, не дай бог, менеджеры. Если модель user должна иметь возможность изменить имя, для этого будет служба updateUserName.
Документация
Давайте не будем забывать то, что редко бывает на нужном уровне. Инфраструктура должна четко определять, как все должно быть задокументировано, и в то же время предоставлять средства для того, чтобы сделать это в стиле проекта.
Swagger — пример инфраструктуры документации. Он определяет способ документирования кода.
Заключение
Прежде чем погрузиться в решение следующей большой проблемы, сначала осмотрите проект и найдите знакомый инфраструктурный шаблон, который может быть полезен для решения проблемы.
Если такого шаблона нет, возможно, команда должна обсудить его введение.
Инфраструктура помогает нам классифицировать фактические шаблоны по значимым группам, которые создают интуицию проекта. Это делает код более удобным для сопровождения. Не всем нужно знать детали реализации, но в этом случае легче понять логику по категориям.
Дайте мне знать, какую инфраструктуру вы предпочитаете для своего проекта.
