— Отдельно для каждой ветки — не пробовал, спросил: нет, проверяется текущая ветка.
— Это ограничения пробной версии, большие проекты тоже можно проверять. Проект приватный или опенсорсный (может ссылку дадите)?
Scrutinizer что-то, конечно, находит, но для интереса попробуйте Php Inspections (EA Extended) (плагин для PhpStorm), посмотрите что нормальные анализаторы могут.
Ну и PVS-Studio, конечно, вообще молодцы и дело говорят.
Ну вы либо пишете грамотную урезанную бету (архитектурно, компонентно и с читаемым кодом), либо одноразовый прототип который нужно выкинуть сразу.
Но не запускать мидлов и отправлять на ревью архитектуры на базе сляпанного на коленке прототипа. Ей богу, это же ад для команды.
Не знаю если честно, просто консолидирую опыт. Вариантов даже больше:
1-3 года — прототип не взлетел
3-6 лет — прототив взлетел, но рынок поменялся
10-15 лет — взлетел, обжился на рынке
10-15 лет может быть обусловлено тем что менеджмент не меняется, и под конец просто хочет стабильного дохода (и плевать на инновации и качество, мне нужно просто выжать всё без дополнительных расходов).
Учтите если будете устраиваться в продуктовую компанию =)
Да ничего нового, обычный жизненный цикл системы: взлетели, стагнировали, упали. У продуктов (коим хабр и является) он составляет 10-15 лет. Последние 5 обычно как раз попытки его оживить, но это редко получается.
Часть автозамены я законтрибутил в PHP CS Fixer: они идут в правильном (на мой взгляд) направлении и надежнее для проекта будет развивать утилиту для коммандной строки (хуки, CI и т.д.).
Напомню, что Php Inspections (EA Extended) — это отдельный плагин, расширяющий возможности штатного анализа в PhpStorm и Idea Ultimate. Ранние анонсы на хабре: раз, два, три.
Пожалуйста =) Для isset/empty можно даже поведение настраивать (часто жаловались).
Фокус на создание сообщества (редкие релизы)
Cоздание места для обсуждения анализатора (тот же твиттер), узнать людей лично.
На это нужно время, поэтому релизы будут реже и больше с фокусом на улучшение существующих проверок.
фокус на коммерческую версию (возможность автоматической замены кода)
Смена лицензии (исходники всё еще в опенсорсе), добавление авто-замены кода. Возможно создание заказных проверок. Сейчас у меня нет времени на добавление авто-замены, и, похоже, что это не критичная функциональность.
Специализация на high-load проектах
Работа с соответсвующими командами (если смогу набрать достаточно контактов) и новые проверки именно для high-load. Уровни репортинга анализатора тоже надо будет пере-определить.
В общем доработка плагина и работа из ИДЕ, то что мы сейчас и делаем.
Сонар оказался никому не нужен, ну нашему ПМу разве что — т.к. он бюджет на него потратил =).
Солюшн Архитекторы плюнули на эту поделку, в работе от него толку нет: так и так код-ревью делать надо.
— Это ограничения пробной версии, большие проекты тоже можно проверять. Проект приватный или опенсорсный (может ссылку дадите)?
Ну и PVS-Studio, конечно, вообще молодцы и дело говорят.
Но не запускать мидлов и отправлять на ревью архитектуры на базе сляпанного на коленке прототипа. Ей богу, это же ад для команды.
10-15 лет может быть обусловлено тем что менеджмент не меняется, и под конец просто хочет стабильного дохода (и плевать на инновации и качество, мне нужно просто выжать всё без дополнительных расходов).
Учтите если будете устраиваться в продуктовую компанию =)
nazarpc инфраструктурно развивает сообщество (CMS, polymer, для Php Inspections (EA Extended) были баг-репорты) и критиковать решения не стоит.
Не нравится решения автолоадинга, докера, архитектуры — делайте пулл реквесты, или создавайте тикеты.
PVS-studio меня и вдохновили, но у них это бизнес и очень круто, что они готовы инвестировать ресурсы в статьи.
Часть автозамены я законтрибутил в PHP CS Fixer: они идут в правильном (на мой взгляд) направлении и надежнее для проекта будет развивать утилиту для коммандной строки (хуки, CI и т.д.).
Обучение, аудит, оценка брать проект или нет или ещё что-то?
Простые случаи вроде запросов в цикле вместо булк-запроса довольно просто реализовать. Хочется случаев посложнее =)
Например нашей системе около восьми лет, сменились несколько команд и приводить в чувство это счастье приходится поэтапно.
Cоздание места для обсуждения анализатора (тот же твиттер), узнать людей лично.
На это нужно время, поэтому релизы будут реже и больше с фокусом на улучшение существующих проверок.
Смена лицензии (исходники всё еще в опенсорсе), добавление авто-замены кода. Возможно создание заказных проверок. Сейчас у меня нет времени на добавление авто-замены, и, похоже, что это не критичная функциональность.
Работа с соответсвующими командами (если смогу набрать достаточно контактов) и новые проверки именно для high-load. Уровни репортинга анализатора тоже надо будет пере-определить.
Сонар оказался никому не нужен, ну нашему ПМу разве что — т.к. он бюджет на него потратил =).
Солюшн Архитекторы плюнули на эту поделку, в работе от него толку нет: так и так код-ревью делать надо.