Как стать автором
Обновить

Сейчас я буду убеждать вас использовать статический анализ в PHP

Время на прочтение 6 мин
Количество просмотров 8.2K
Всего голосов 26: ↑26 и ↓0 +26
Комментарии 18

Комментарии 18

Куча народа даже плагин Php Inspections ​(EA Extended) не ставят, не то что какие-то сторонние анализаторы, которые ещё и настраивать нужно (

Куча народа даже с компьютером не в ладах, не то что какие-то IDE которые ещё и установить нужно :)


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

Спросил у знакомого с крупной компании: «а что ты используешь?», а он ошарашил: «Notepad++». Я очень удивился, спросил: «эм, а как же IDE, подсветка измененных строк, переход к объявлению функции, автодополнение методов?» ответил: «а зачем?».
Спросил о тестировании, деплое: «ну мы что-то там думали тестить, но мы этим не заморачиваемся». И это, кстати, в одном из крупнейших агрегаторов цен Украины.
А вы о каких-то анализаторах говорите…

Php Inspections — тоже сторонний анализатор, который ещё и настраивать нужно. Смотрю на его вывод в окне редактирования, только если несколько ошибок в файлк подсвечивает, а не сотни. Если в проекте активно используется динамическая "магия" PHP, то усилия на поддержку статанализаторов, имхо, не окупаются. Проще проект полностью переписать с нуля, отказавшись от магии в нём и/или библиотек/фреймворков, её использующих (привет, моя боль Laravel+Eloquent), чем статически объявить эту магию в аннотациях и держать её актуальной.

Как-то пробовал внедрить psalm на проекте на базе Laravel. Практически нереально из-за кучи магии. Там даже с обычным phpdoc проблемы, в IDE всё красное "method/property not found in class Model" и т. п., а с каким-то сторонним пакетом типа ide-support (которому ещ' и база запущенная нужна) красное из ошибок множественніх деклараций и навигация сломана

Там даже с обычным phpdoc проблемы, в IDE всё красное

Для Laravel-а практически обязателен https://github.com/barryvdh/laravel-ide-helper, который решает почти все проблемы с автокоплитом в PHPStorm-е :) (быстрее бы еще фабрики смержили...)

Он, насколько я помню, требует доступа к базе при разработке (или локально, или открытой извне, в ssh-тонелли не умеет). И, главное, лишь уменьшает количество "красного", в частности провоцируя ошибки типа "в проекте несколько деклараций класса User", и ухудшая UX для, например, навигации: приходится вібирать на метод какого User мі сейчас переходим.

Не, он ничего не требует, кроме, разве что PHPStorm-а, для которого он генерирует метадату (автокоплит для контейнера и переопределение типа возвращаемого значения некоторых методов). Дополнительно к ней он может создавать псевдоклассы для фасадов и Macroable, ну и генерировать phpdoc с полями для моделей (базу при этом использует туже что и сама модель).

ну и генерировать phpdoc с полями для моделей (базу при этом использует туже что и сама модель).

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

Для моделей он вот такое генерит:


/**
 * App\Models\Site
 *
 * @property int    $id
 * @property string $type
 * @property string $title
 * @property string $email
 * @property string $url
 * @method static \Illuminate\Database\Eloquent\Builder|Site newModelQuery()
 * @method static \Illuminate\Database\Eloquent\Builder|Site newQuery()
 * @method static \Illuminate\Database\Eloquent\Builder|Site query()
 * @method static \Illuminate\Database\Eloquent\Builder|Site whereEmail($value)
 * @method static \Illuminate\Database\Eloquent\Builder|Site whereId($value)
 * @method static \Illuminate\Database\Eloquent\Builder|Site whereThrottle($value)
 * @method static \Illuminate\Database\Eloquent\Builder|Site whereTitle($value)
 * @method static \Illuminate\Database\Eloquent\Builder|Site whereType($value)
 * @method static \Illuminate\Database\Eloquent\Builder|Site whereUrl($value)
 * @mixin \Eloquent
 */
class Site extends Model {}

Но для этого ему нужен доступ к базе на момент генерации. Пробовали делать в CI — не понравилось.

Но для этого ему нужен доступ к базе на момент генерации.

Так это логично, как иначе он узнает какие поля есть у таблицы?

Миграции может проанализировать. )


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

Миграции может проанализировать. )

Ну… у меня оно raw sql например)

sql сервер же из них таблички собирает как-то )) Дп и у того же jetbrains статанализатор sql


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

статанализатор sql

Проблема в том что Laravel из коробки использует php для миграций, но оно поддерживает далеко не всё что есть в sql (из совсем банального — нету енумов), поэтому в реальности миграции все равно содержат sql, который еще и привязан к конкретной базе (собственно это одна из основных причин полного перехода на raw sql).


А вообще костыли всё это.

Ага, но ide-helper сильно всё упрощает :) И кстати, вон вроде плагин есть, который под капотом использует ide-helper (сам не пробовал).

Ага, но ide-helper сильно всё упрощает :)

Создаём себе трудности и героически их преодолеваем пакетами и плагинами :) Надо бы попробовать ещё раз, может Makefile какой сделать, который будет в докере базу поднимать и вотчер запускать, который будет миграции мониторить, накатывать их, а потом ide-helper запускать. Или CI настроить так чтобы она на коммит в репу, запускала ide-helper и коммитила в эту же репу в эту ветку. Надо только убедиться, что зацткливаться не будет.

Удобнее ли использовать SonarQube с учетом того, что статического кода не всегда достаточно, а ставить кучу отдельных свистелок и интегрировать в CI их неудобно?
Зарегистрируйтесь на Хабре , чтобы оставить комментарий