Laravel: 4 инструмента для статического анализа

Источник: «Laravel Tooling: 4 tools for static analysis»
За эти годы я научился пользоваться целым рядом удивительных инструментов используемых для разработки приложений на PHP и Laravel.

Что такое инструменты статического анализа?

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

Pint

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

На момент написания, большая часть PHP кода будет разрабатываться в соответствии со стандартом PSR-12, у нас так же был PSR-1 и устаревший стандарт PSR-2.

Стандарты PSR охватывают не всё, хотя часто полезно посмотреть, какие дополнительные правила можно применить.

Ключевой вывод и преимущества — удобство чтения и совместная работа. Если вы работаете самостоятельно, это не обязательно принесёт огромные улучшения. Если вы работаете в команде это принесёт всем большую пользу. Некоторые стандарты PSR помогают уменьшить количество конфликтов при слиянии. В равной степени простое установление набора общих правил означает, что код будет написан таким образом, чтобы ваш мозг быстрее воспринимал его и понимал из мышечной памяти.

PHPStan (& Larastan)

PHPStan хорошо зарекомендовал себя как полезный инструмент для PHP-разработчиков во всём мире. Цель PHPStan — посмотреть как взаимодействует код. Например, он может посмотреть на использование переменной и определить, будет ли строковая переменная использоваться с функцией в качестве аргумента массива. Это, конечно, было бы ошибкой времени исполнения, если бы это произошло. Точно так же PHPStan может найти неиспользуемый код.

PHPStan невероятно полезен, так как многие разработчики стремятся воспользоваться преимуществом подсказки типа, которые продвинули вперёд PHP7 и PHP8. Это нелегко сделать не найдя всех мест в проекте без подсказки типа. PHPStan может сделать это выполнив поиск там, где аргументы или возвращаемый тип не задокументированы подсказкой типа или тегом PHPDoc.

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

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

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

PHP Insights

Хочу сказать, что в целом этот инструмент удобен, но поначалу может быть немного сложным. В нём задействовано несколько различных вещей статического анализа. PHP Insights предоставит четыре группы оценок: код, сложность, архитектура и стиль.

Начну с понимания стиля, по сути это будет такой же вид обработки, как и в Pint, но неплохо иметь оценку. Он также подберёт несколько других вещей, которых нет в Pint, например, подсчёт строк.

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

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

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

В конечном итоге я бы сказал, что PHP Insights интересен и отлично подходит как инструмент для быстрой оценки качества кода, а затем использовать начальную оценку, чтобы увидеть, движетесь ли в правильном направление проводя рефакторинг кода. Но вам определённо нужно потратить некоторое время на формирование собственного мнения о том, какие правила используются или не используются при создании таких показателей.

Rector

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

Существует простой набор правил для таких вещей, как PHP и даже PHPunit, которые стоит использовать. Но так же есть правила для выполнения обновления кода Laravel, изменение фабрик до PHP 7 на более новы стили. Стоит обратить внимание, что если вы работаете с Laravel, раньше правила устанавливались с Rector, а теперь устанавливаются в своём собственном пакете.

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

Я считаю, что Rector — инструмент, к которому в будущем должно привыкнуть всё больше PHP-разработчиков. Это может изменить ситуацию между вашими разработчиками, использующими устаревшие операции и функции PHP, а так же упростить обновление кодовых баз, которые можно было бы делать с некоторой дополнительной любовью.

Ещё одна вещь…

Если вы не заметили у всех этих инструментов есть одна общая черта: три из четырёх этих эффективных инструментов для Laravel разработчиков созданы известным разработчиком Нуно Мадуро.

Дополнительные материалы

Предыдущая Статья

Laravel: Внедрение зависимости и Сервис контейнер

Следующая Статья

PHP: Зачем следовать PSR-20