Челендж на 2026

Достаточно не разумное мнение. Ты понимаешь, что эти инструменты дают?  Дело тут совсем не в "бум-бум". А в автоматизации процессов. 

Эти все инструменты (тестирование, проверка безопасности) не отменяют необходимости знаний. Знания по прежнему необходимы. Более того при использовании сторонних проектов ты не будешь изучать чужой код досканально. Ну представь некий Вася купил у тебя фреймворк. Он должен просто верить что там все ок с безопасностью? Или ты реально веришь в свою гениальность и думаешь, что твой фреймворк по определению не возможно взломать? если да то ты очень наивен.

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

Для примера. я работаю с проектами Битрикс, тут я доверяю вендору и своевременно обновляю. Но есть маркет модулей, и вот там вот я ценю работу вендора, который модули прогоняет в плане безопасности и убирает с маркета модули с уязвимостями. (И по моему модулю приходило уведомление - но  у меня модуль для работы с git и там есть некоторый функционал, который может быть опасен. Я им письмо просто пояснительное написал)

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

1. Тебе будет плевать если зальют модуль с уязвимостью (и бросят тень на твой фреймворк и его экосистему)

2. Будешь каждый модуль лично проверять просматривая весь код, и каждое обновление каждого модул?

3. Применишь инструмент (возможно даже "быстренько"  напишешь свой) который будет автоматом проверять.

4. Что то иное?

Защита тут не в плане "не дать кому то посмотреть исходники" для этого есть совершенно другие инструменты.

Sly32 кстати, конечно же статанализ использую.

В том то и дело, что он не понимает совсем. Мы с тобой целую страницу обсуждаем тему, не раз было подчеркнуто, что разговор о ПАКЕТАХ   а не кодовой базе и тут приходит арбнет и рожает вот это вот все... Причем сам рассказывал как поломали его несуществующую систему.
Тратить время на дилетанта неохота... 

Тут вот Fable 5.1 вышел, Astra  на подлете. А он все исходники прячет))

Можно поподрбнее?

Это уже про собственный код. PHPStan Я так понимаю в стане питона это mypy и pylint

Ловит "опасные паттерны", проверяет типизацию (даже более "конкретно" чем позволяет сам язык), можно настроить запрет каких-то функцию (например eval - который любим хацкерами). Можно добавлять свои правила  и регулировать уровень его "паранои" :)

PS Возникла идея... Прогоню ка я им ту версию что у меня есть фреймворка от автора которому не нужны ни тесты ни инструменты безопасности :)  Публиковать детали не буду, возможно ему выхлоп покажу.... :) Уверен там стан на 0 уровне офигеет, а на 9ом вообще порятнку на 100500 строк выдаст

ну, линтеры - наше все, это на уровне IDE  давно уже. А дополнительно Flake8 - можно даже цикломатическую сложность чекать. Black -  сам форматирует правильно код.
Кроме того, часто ставлю pre-commit, который просто не даст запушить коммит если он не пройдет тесты

И кстати про тесты - как с ними дела? Я вот в лерне честно говоря подзабил на них, в результате покрытие упало до 48% - это, конкчно, позор... каюсь

😂 пожалей линтер. Было бы конечно интересно результат узнать, хотя тут и гадать не надо)

В этом проекте все полностью покрыто. Даже информеры есть в readme. вот например для шаблонизатора 

1 - Это сторонний сервис. Он там глубже чекает. Например плохой бал выдаст если слишком большая глубина условных.

2.- Степень покрытия тестами

3 - прогон  тестов в рзаных версиях php , для шаблонизатора это 8.5 и 8.6 (это будущий релиз) , фреймворк  еще и 8.4

Это и есть цикломатическая сложность. Каждый if - новое ветвление.

Нет ну все таки слэш глаза режет прям - непонятно что закрывает цикл. 

надо было уж тогда 

{% /endif %}
{% /endforeach%}

А то мне как слепому кажется что это новое условие

Подумаю еще... :)

это уже дублирование. тут выбирать "/" или "end" но не вместе

Полезная штука конечно. В рабочих проектах такое редко (все же тоже бюджета требует). Но местами позволяет на раннем этапе переосмыслить что то или обратить на что то дополнительное внимание. Написание доки тоже такой же эффект дает :). Но на разработку через тестирование не перешел :)