Ответ
В PHP-проектах я настраиваю и использую комплекс инструментов для статического анализа, чтобы поддерживать высокое качество кода на ранних этапах.
Основной стек:
-
PHP_CodeSniffer (PHPCS) + PHP-CS-Fixer. Первый — для проверки, второй — для автоматического исправления стиля кода. Использую стандарт PSR-12 и кастомные правила проекта. Конфигурация в
phpcs.xml.dist:<?xml version="1.0"?> <ruleset name="MyProject"> <rule ref="PSR12"/> <rule ref="SlevomatCodingStandard.TypeHints.PropertyTypeHint"/> <file>src</file> <file>tests</file> <exclude-pattern>*/vendor/*</exclude-pattern> </ruleset> -
PHPStan. Запускаю на максимальном уровне (
level: 9) для строгого контроля типов и поиска скрытых ошибок. Интегрирую его в CI/CD пайплайн, чтобы проверка была обязательным этапом.# phpstan.neon parameters: level: max paths: - src checkMissingIterableValueType: false -
Psalm. Использую в дополнение к PHPStan в некоторых проектах, так как он предлагает уникальные проверки, особенно для аннотаций типов в PHPDoc и поиска возможных SQL-инъекций.
Интеграция в процесс:
Я настраиваю скрипты в composer.json, чтобы команды были стандартизированы для всех разработчиков:
{
"scripts": {
"cs-check": "phpcs",
"cs-fix": "phpcbf",
"stan": "phpstan analyse",
"analyse": ["@cs-check", "@stan"]
}
}Запуск composer analyse выполняет всю цепочку проверок. Это позволяет отлавливать проблемы до коммита и код-ревью, значительно экономя время команды.
Ответ 18+ 🔞
Ну ты представляешь, какая история — сидишь ты такой, пишешь код, а потом раз — и на тебе, в прод вылезает какая-нибудь дичь, потому что кто-то забыл проверить тип переменной. Ёпта, я с этим бороться начал, как Шерлок Холмс с преступностью. Настроил себе целый арсенал, чтобы код был не просто рабочий, а чтоб блестел, сука, как жопа у младенца.
Вот мой основной набор для выноса мозга коду:
-
PHP_CodeSniffer (PHPCS) + PHP-CS-Fixer. Первый — это как злой завхоз, который ходит и тычет палкой: «Ага, тут отступ не четыре пробела, а три! Пиздец!». А второй — его брат-близнец, но с отвёрткой, который сразу всё и чинит. Я им говорю — живите по стандарту PSR-12, и не рыпайтесь. Конфиг у меня в
phpcs.xml.distлежит, простой как три копейки:<?xml version="1.0"?> <ruleset name="MyProject"> <rule ref="PSR12"/> <rule ref="SlevomatCodingStandard.TypeHints.PropertyTypeHint"/> <file>src</file> <file>tests</file> <exclude-pattern>*/vendor/*</exclude-pattern> </ruleset>Главное — не забыть выпихнуть папку
vendor, а то он там начнёт ворчать на чужие библиотеки, ядрана вошь. -
PHPStan. А вот это, блядь, мой главный каратель. Ставлю ему уровень сложности на максимум (
level: 9), и он начинает копать так, будто ищет клад в твоём коде. Находит такое, от чего сам от себя охуеешь — типы не те, возможные null'ы, где их быть не должно. Просто терпения ноль ебать у этой штуки. Кидаю его в CI/CD, чтобы ни одна строчка не проскочила без досмотра.# phpstan.neon parameters: level: max paths: - src checkMissingIterableValueType: false -
Psalm. Его я подключаю иногда, когда чувствую, что PHPStan отдохнул. У него свой взгляд на вещи, особенно он любит поковыряться в PHPDoc'ах и порыскать, нет ли где случайной SQL-инъекции, которую все проглядели. Два таких детектива — надёжнее.
Как я это всё в дело впариваю:
А хитрая жопа-то в чём? В том, чтобы никто не забыл этим пользоваться. Я в composer.json прописываю скрипты, и всё — приказ команде.
{
"scripts": {
"cs-check": "phpcs",
"cs-fix": "phpcbf",
"stan": "phpstan analyse",
"analyse": ["@cs-check", "@stan"]
}
}Теперь любой чувак перед тем, как закоммитить свою гениальную, блядь, идею, просто запускает composer analyse и получает по шапке от всех этих инструментов сразу. Это ж овердохуища времени экономит на код-ревью, потому что все очевидные косяки уже выловлены. И в душе спокойно — волнение ебать нулевое, когда пушаешь в мастер.