Является ли весь код в каталоге vendor инфраструктурным и что такое основной код?

Содержание

1. Является ли весь код вендора кодом инфраструктуры?
2. Модульные тесты и основной код
3. Большая часть, но не весь код вендора является кодом инфраструктуры

Опубликовано 22 февраля 2020 года Матиасом Нобаком

Во время недавнего курса обучения Advanced Web Application Architecture мы обсуждали различие между инфраструктурным кодом и не инфраструктурным, который обычно называется основным кодом. Разницу между этими двумя понятиями можно резюмировать так: «все в vendor-каталоге - это код инфраструктуры».Но я не согласен с этим, и вот почему.

Является ли весь код вендора кодом инфраструктуры?

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

• Правило 1: Базовый код не зависит напрямую от внешних систем и не зависит от кода, написанного для взаимодействия с конкретным типом внешней системы.
• Правило 2: Базовому коду не требуется конкретная среда для выполнения, и при этом он не имеет зависимостей, предназначенных для запуска только в определенном контексте.

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

Эти правила ничего не говорят о том, расположен ли основной код в директории src/ или vendor/, и это справедливо. Представьте, что у Вас есть кусок кода, который Вы можете вызывать как основной код, потому что он соответствует его определению. Если Вы сейчас перенесете этот код в отдельный репозиторий на GitHub, опубликуете его как пакет и установите его в каталоге vendor/ вашего проекта с помощью Composer, станет ли этот кусок кода внезапно кодом инфраструктуры? Конечно, нет. Расположение кода не определяет, что это за код.

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

Модульные тесты и основной код

Это может напомнить Вам об определении модульного теста Майкла Фезера. Тест не является модульным тестом, если:

1. Общается с базой данных
2. Общается по сети
3. Это касается файловой системы

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

Большая часть, но не весь код вендора является кодом инфраструктуры

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

Давайте посмотрим на некоторые примеры кода, который расположен в вендоре, но не будет (согласно моим правилам) называться кодом инфраструктуры:

• Библиотека диспетчера событий
• Библиотека утверждений
• Библиотека объектов значения

Библиотеки, которые занимаются только преобразованием данных (например, преобразователь или сериализатор данных), также могут рассматриваться как не инфраструктурный код. На практике Вы можете использовать следующий контрольный список, чтобы узнать, является ли код (где бы он ни находился, в src или в vendor) не инфраструктурным кодом:

• Класс используется где угодно и его можно свободно вызывать любым из методов
• Код не имеет статических зависимостей (фасадов, реестров служб и т. д.), Зависимостей от глобального состояния ($ _SERVER, $ _POST и т. Д.). Все его зависимости предоставляются в качестве аргументов конструктора. Ни одна из зависимостей не является самим кодом инфраструктуры.

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