нормальный подход, работает

но должен быть в команде один а лучше два человека которые все это понимают

иначе "факапы" обходятся дороже

ну те кто отвечают за проект головой те в курсе всего

+ принияли за стандарт писать доки

не пхп и апи док

а полные в конфлюенсе

у меня тоже доки по api

ну доки по апи это одно

только в apiary

у нас нелимо

или как он там

Доки, зачастую, устаревают быстро и неактуально. Более лучше писать бизнес-сценарии на бехате, каком-нибудь

у меня сначала дока а потом уже код, так что "нельмио" мне не подходит

http://symfony.com/doc/current/bundles/NelmioApiDocBundle/index.html

Доки, зачастую, устаревают быстро и неактуально. Более лучше писать бизнес-сценарии на бехате, каком-нибудь

плюсую, но это надо что бы вся команда работала по ним и стэкхолдеры имели возможность их читать

Сергей, привет :)

http://jsonapi.org/

Как тесен мир

Здаровки

Ты меня не помнишь, скорее всего. Года полтора к вам собеседовался и СТО завернул меня

Помню)

и не согласен с Ником)

ну да ладно)

он в те времена сильно идейным был

а статическим анализом балуется кто

?

на качество?

плюсую, но это надо что бы вся команда работала по ним и стэкхолдеры имели возможность их читать

Мы сейчас на нашем проекте это практикуем, особенно для сложных бизнес-фичей, типа расчёта налогов для Норвегии :) Написали бизнес-сценарии, показали конечным пользователям/заказчикам, получили от них фидбек и го имплеменировать

а статическим анализом балуется кто

Скрутинайзер у нас, если это про это

у нас от симфони анализатор и сонар

блин пойду в понедельник просить покупку скрутинайзера...

Так вот, бехат даёт свои плоды, особенно когда надо потом в написанном менять + рассказать кому-то как что работает и почему

у нас бизнес аналитики не хотят...(

Может сценарии слишком сложные?

врядли

я думаю просто не умеют и не хотят)

https://gist.github.com/fesor/370b3486cf7ee96af34fcbb286bd6563

хороший материал

дописать бы его...

я только благодаря тебе вспомнил что он у меня есть

а не, благодаря @CawaKharkov

Так вот, бехат даёт свои плоды, особенно когда надо потом в написанном менять + рассказать кому-то как что работает и почему

а где храните фичаспеки?

пользуетесь тулзами какими или тупо в git?

для кукумбера видел неплохой сервис для организации спецификации по проекту на основе фичаспек

В проекте, в папке features/

Просто в битбакет посылаем почитать, если что

Более навороченного пока не прикручивали за ненадобностью

я сейчас подтягиваю знания по ООП в пхп, с чего бы начать, готов хоть с основ начать. Сейчас открыл книгу Domain-driven design in PHP, и что-то как-то тугой идет

я сейчас подтягиваю знания по ООП в пхп, с чего бы начать, готов хоть с основ начать. Сейчас открыл книгу Domain-driven design in PHP, и что-то как-то тугой идет

Эванса лучше почитать в начале, причем почитать и через пол годика повторить

а как же зандастра?

но лучше прокачивать скил в рефакторинге

Где-то рекомендовали мне Зандстру - РНР Объекты, шаблоны и методики программирования

а как же зандастра?

не читал не знаю

видел оглавление - оно не поможет)

я тоже но все говорят хорошая

с работы напоминание прилетело, никто не забыл?

Коллеги напоминаю всем, что в выходные в ночь с 3-го на 4-е декабря будет перевод времени на час вперед. Прошу учесть это в работе.

я тоже но все говорят хорошая

ну оно как гайд скорее. Тип ознакомился и угблубляешься через другие книги в отдельные топики

я сейчас подтягиваю знания по ООП в пхп, с чего бы начать, готов хоть с основ начать. Сейчас открыл книгу Domain-driven design in PHP, и что-то как-то тугой идет

я тебе рекомендую помимо "подтягивать знания по ООП" чаще заниматься рефакторингом. То есть прошариться в приемах рефакторинга и в тестах.

так же стоит поразбираться "зачем нужна инкапсуляция", чаще делать ретроспективу принятых на проекте решений

особенно в случае багов или регрессий

особенно регрессий

почитать про SOLID и GRASP

Зандстра мутный, реализации у него не очень понятные

тебе нужно не реализацию смотреть

а идею

http://www.slideshare.net/rdohms/bettercode-phpbenelux212alternate

я просто через реализации пытаюсь идеи понять

привычка

нужно пытаться еще проникнуться идеей какие проблемы эта реализация решает

многие этим грешат, заучивают например... MVC

что такое контроллер

и начинают фигачить

а зачем его придумали и какие проблемы решает - разбираются на уровне "введение в одну из статей"

с большего же "все говорят что надо ну значит надо"

еще можно попробовать поразбираться с функциональным программированием

там идеи чуть менее искажены исторически

и сильно пересекаются с ООП

видимо придется сменить работу. У меня нет таких проектов, в которых можно что-то рефакторить

либо посмотреть OS