Т.е. Вроде что-то делаю, с докой и гуглом вообще все что бизнес просит. Но дальше цепочки что ты написал не понимал

в целом рекомендую тогда попробовать написать свой контейнер зависимостей - он покрывает наверное 80% того что в этом флоу из "интересного"

там из того что не входит в это - роутинг, тут регулярки можно будет подтянуть)

Это следующий в списке задач пункт

покажи список)

А роутинг без регепса уже писал)

А роутинг без регепса уже писал)

и как он работает?)

Пса выгуляю скину)

ну просто если он у тебя без регуляро - есть вероятность что ты ничему не научился)

оно конечно не только за счет регулярок можно, много чего можно

префиксное дерево например

но не как в yii - /:controller/:action

Да никак, просто по урлу находил контроллер и экшен

Самый примитив

ясно, ну так чему ты научился?)

Что во первых магии в нем нет, а во вторых писать надо минимум с конфигом и нормальным диспетчером, ну и узнал про магию php вида (new $controller)->$action()

Год назад дело было

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

Мелочь вроде, но хоть что-то

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

На самом деле рост при написание фреймворка маленький , мне больше показал на слабые места

Что во первых магии в нем нет, а во вторых писать надо минимум с конфигом и нормальным диспетчером, ну и узнал про магию php вида (new $controller)->$action()

этим не роутер должен заниматься

А-ля слабое понимание внутрянки php, слабое знание паттернов

На самом деле рост при написание фреймворка маленький , мне больше показал на слабые места

ну если выводы делаешь - уже хорошо)

Ну да

Диспетчер нужен

А, я ещё абстрактными классами наловчился пользоваться на первом фреймворке

Ну и про рефлекшон узнал

И попользовался

:D

Правда для херни, сделал класс константы которого можно форычем перебрать

И cli узнал

Так что смысл имеет, но лучше в интересную фирму на интересный проект.с ментором

А, я ещё абстрактными классами наловчился пользоваться на первом фреймворке

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

и да - тесты

Вооот, я дошёл до трейтов и самодостаточных классах

А вот с тестами беда

На работе тимлид их не хочет

о_О

На работе тимлид их не хочет

ну и правильно, ты ж не умеешь тестируемый код писать) какой смысл тратить ресурсы впустую)

тимлид не хочет, чтоб ты писал тесты?

Попробую на своём фреймворке, но слабо представляю как тестить

Добрый вечер. А кто может сталкивался, laravelcollective/html при создании поля, например: Form::hidden('methodName', 'saveItemKind') перед тем как подставить значение saveItemKind, проверяет $this->request->input('methodName'). и если таковое не пустое, то подставляет именно его вместо 'saveItemKind'.

Попробую на своём фреймворке, но слабо представляю как тестить

вот на эту тему можешь спокойно тут спрашивать

У нас блин команда из трёх программистов ) никто тесты не пишет

тимлид не хочет, чтоб ты писал тесты?

это нормальная ситуация. тесты мало кто пишет. Даже приемочные

Вообще

И на прошлых работах та же беда

и тем более нет смысла писать тесты если ты будешь их один из трех писать. Ты забьешь тупо

это нормальная ситуация. тесты мало кто пишет. Даже приемочные

не понимаю, что здесь нормального)

НО! можно научиться а потом научить других)

не понимаю, что здесь нормального)

"норма" не всегда хорошо

«На тесты нет времени»

«На тесты нет времени»

баги/регрессии есть?

"норма" не всегда хорошо

мысль понял, да

Баги есть, но мало

ну тогда тесты не особо нужны)

Получается надежный код писать + я ревью заставил всех делать

а на это время есть)

ну как, на самом деле это проще

Хоть как-то от херни бережемся

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

и если команда вся не умеет в них - то обречено

Ну и дев сервер поднял который стягивает ветку develop и там все тестят

Вручную пм и пара ребят что в админке работают

Ну я это и понимаю и не понимаю. Чем раньше бы начали тем проще бы было, кодовая база маленькая была

ERROR: S client not available

А сейчас покрыть все тестами месяц займёт

читать AAA

а тесты в первую очередь писать для себя

Что читать? Оо

http://wiki.c2.com/?ArrangeActAssert

Благодарю

:) вот ещё что-то новое узнаю

А сейчас покрыть все тестами месяц займёт

тебе не надо все покрывать)

еще добавлю

https://gist.github.com/fesor/db60b4995880925b720be9c7cf75543f

Приду почитаю, самому пока видеться так, юнит тесты только на «сложные» участки кода, там где может вкрасться ошибка, например расчёт величины зависящий от 10 параметров по какой нибудь дикой формуле, а вот функциональные тесты должны покрывать все приложение

Ребята привет, часто встречаю в чужих сорсах такое /** * @var \Ramsey\Uuid\Uuid */ private $id; public function __construct() { $this->id = Uuid::uuid4(); } Выглядит как нарушение инверсии зависимостей и я бы сделал так /** * @var \Ramsey\Uuid\UuidInterface */ private $id; public function __construct(UuidInterface $uuid) { $this->id = $uuid; } Но почему тогда первый вариант конструктора так часто всречается в примерах, в том числе у авторитетных разработчиков(например у ocramius)?

Я так думаю, что в первом варианте - сущность

Да, и во втором тоже.

да, но сущность с зависимостью... как ее сериализовывать/десериализовывать?

будет ли она валидной после десериализации, например? нет

десериализовывать сущности грешно

грешновато. но пример отличный

Ну да, именованные конструкторы использовать.

вот в этом варианте, например, uuid используется как identity. никто не мешает сделать у сущности бизнесовый статичный метод, подразумевающий создание новой сущности (например, ::register в случае , допустим, регистрации нового пользователя), а туда уже прокинуть конкретное значение id (в параметрах метода, да)

причем извне неважно, чем получен id (сиквенс, uuid)

правда, я бы тут id еще завернул в valueobject

Зачем?

ну, допустим, id пользователя не может быть 0 и меньше

такой себе инвариант

https://buildplease.com/pages/vo-ids/

Ну вот я сейчас глянул. Доктрина не вызывает конструктор сущности и не рекоментует сериализовать сущности.

Значит через конструктор допустимо указывать зависимости

https://buildplease.com/pages/vo-ids/

годно, схоронил

https://buildplease.com/pages/vo-ids/

Спасибо

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

например