флейм о трейтах

[fixxxer]

Чтобы рефакторить, нужно понимать, как делать правильно, в какую сторону менять код. Более того, чтобы рефакторить, нужно чётко понимать текущие бизнес-требования, которые могут уже как-то образом быть разманы или даже утрачены (в том смысле, что никто точно не знает, какое поведение правильно), чтобы не сломать что-то. Т.е. опять-таки, всё идёт к тому, что нужно писать тесты, документирующие поведение системы (BDD), нужно уделять особое внимание бизнес-логике, модели (DDD). Я на своём опыте понимаю, что это не просто красивые слова, хотя вот относительно недавно (года 2 назад?), очень скептически относился к тому же BDD. Это становится понятно после боли в заднице от legacy кода.

Собственно, основной мой пойнт в том, что я не вижу проблемы писать больше, если это снижает риски. Написание кода — это вещь, на которую уходит меньшая часть времени в любом случае.

Да, но чаще ты не знаешь, будут ли у тебя эти 5 лет развития, и технический долг при разработке minimum viable product создается осознанно, потому что еще неизвестно, будет ли, кому его отдавать. И в этом смысле говно в трейте лучше, чем ручной копипаст говна =)

Особого смысла в BDD я, кстати, так и не уловил. В том смысле, что примерно то же самое я всегда, еще не зная слова BDD и называя это функциональными или интеграционными тестамт, делал phpunit-ом (да, не юнит тесты на юнит-фреймворке, и что) и до сих пор не врубаюсь, зачем нужны эти new shiny фреймворки, кроме syntax sugar.

 

[Absinthe]

зачем нужны эти new shiny фреймворки, кроме syntax sugar.

А зачем нужны PHP-фреймворки, когда проще код херачить?
Удобнее с ними, когда их знаешь.
Правда я отрицательно отношусь к Story BDD и предпочитаю спецификации.

 

[fixxxer]

А зачем нужны PHP-фреймворки, когда проще код херачить?

Фреймворки, не дающие ничего кроме syntax sugar, действительно не нужны. Я, правда, таких не припоминаю.

Касаемо stories, тут дело такое - эти самые stories обычно формулируются в общем виде, типа "хочу, чтобы юзер мог эцсамое", а нормальная бизнес-логика рождается по ходу дела, при детализации бизнес-логики этой самой story и написании юнит-тестов =)

 

[Вурдалак]

Не, почему, в Story ты пишешь конкретные кейсы, которые потом маппятся на функциональный тест. Если же выясняются новые детали, которые никак не упоминаются в Story-спецификации, то ты просто дописываешь новый сценарий или уточняешь существующий. Я вижу в Story 2 полезных свойства:

1. Автоматически тестируемые спецификации в виде естественного языка, которые являются единственным источником знаний о текущих требованиях для всех участников (менеджеры, программисты, QA). То есть если менеджеры описывают требования в какой-нибудь wiki, то никто не сможет быть уверенным, что твои функциональные тесты на Selenium соответствуют этой доке, хотя бы банально потому, что с очередным апдейтом системы могут забыть отредактировать wiki.
2. Помогает формировать общий язык (aka Ubiquitous Language) с целью избавления от двусмысленности одной и той же фразы/утверждения в разных контекстах. Здесь имеется в виду, что один и тот же step (в терминологии Gherkin) во всех *.feature файлах маппится на один и тот же код, что позволяет избавить фразу «Given User is banned» от двусмысленности: забанен только его аккаунт или, например, в это понятие включается и бан по IP? Будут что-то одно, о чём вы заранее договоритесь.

Хотя реально у меня не было опыта с BDD, но здравый смысл тут определённо есть.

 

[Absinthe]

Вурдалак, вот начинали с Behat по этим же причинам, посмотрели на Codeception... сравнили затрачиваемое время, поняли, что аналитики читать истории (чтобы сравнить с wiki) не будут. Перешли на Codeception.
ИМХО Story BDD хорош только в теории.

Фреймворки, не дающие ничего кроме syntax sugar, действительно не нужны. Я, правда, таких не припоминаю.

А зачем пишешь на PHP, который всего лишь синтаксический сахар над языками 1-2 поколения?