Alexander
тормозит?
Alexander
ломается при изменениях?
Anton
Дорого внедрять новое
Alexander
почему?
Anton
Ломается переодически
Anton
Метод на 500 строк например
Anton
Нарушены границы контекста и единственной обязанности.
Anton
Очень сложно это поддерживать.
Alexander
не не не
Anton
?
Alexander
надо идти от проблем
Alexander
а не от того, какая там ответственность нарушена
Anton
Ага
Alexander
500 строк. Почему это проблема?
Alexander
Как часто именно в этом методе совершаются правки? (это, кстати, из git можно вытянуть)
Anton
потому что любое малейшее изменение бизнес логики заставляет искать во многих местах, и править код
Anton
тогда как при правильной архитектуре, такого бы не было
Anton
практически всегда в
Anton
в этом классе на 4к строк
Alexander
именно в этом методе на 500 строк?
Alexander
метрика, кстати, зовётся code churn
Anton
именно в этом классе из 37 методов
Anton
и нескольких по 500 строк
Anton
это основная сущность - заявка. много статусов и состояний
Anton
до этого я работал на другом проекте, где были мелкие методы, все изолированно. и правки внедрялись быстро, тесты было легко поддерживать
Ilya
Нарушены границы контекста и единственной обязанности.
> Yii > принцип единственной ответственности))))
Anton
а тут и с тестами беда начинается
Anton
и много мест где Order::find... дублируется
Anton
и я понимаю как можно сделать правильно. выделить скоуп запросы, их назвать по сути бизнеса
Anton
в yii вроде это activeQuery
Anton
переместить все запросы в модели, очень сильно сократится дублирование. Уже профит. Это позволит реффакторить дальше
Anton
> Yii > принцип единственной ответственности))))
в чем проблема? я не говорю о каком то 100% соблюдении этого. Здравый смысл
Ilya
Всё правильно говоришь
Anton
в смысле папка?
Alexander
я просто про то, что начинать надо с подсчёта churn
Vitaliy
в смысле папка?
Ну как в байсик приложении, и там Order extends Model
Alexander
и вычищать самое больное в первую очередь
Anton
Order (ar модель. анемичная) -> OrderService (божественный класс где все запросы find и остальная бизнес логика) -> OrderController (тонкий)
Alexander
я не уверен, что репозитории — это оно
Alexander
предпочитаю не гадать, когда есть метрики чёткие
Alexey
Без тестов вычищать это стрельба в голову
Alexander
не всегда
Anton
все покрыто тестами
Anton
1000 тестов
Anton
в этом плане плюс
Dmitry
А можно какой то пример, какая задача тяжела в выполнении на yii2, и для каких "легких" целей symphony лучше не использовать?
Элементарно. Если принесли замысловатую вёрстку не на Bootstrap, то ActiveForm и LinkPager не подходит. Если нужны замысловатые таблицы с colspan и rowspan, то выбрасываем GridView. Если проектируем сложные сущности со вложенными объектами-значениями, то сильно перепиливаем ActiveRecord или меняем его на Doctrine. Если подключаем сторонние компоненты, работающие по PSR, то пишем адаптеры PSR. Если хотим делать фреймворконезависимые PSR-7 контроллеры, то нужно самому программировать трансформеры для запроса и ответа и адаптеры для контроллеров. Если хотим делать маршрутизацию по именам маршрутов, а не по именам контроллеров и экшенов, то нужно переписать фреймворковский UrlManager или заменить на другой. Но у него нет интерфейса, поэтому придётся наследоваться. Потом хотим добавить мультиязычность в адресе. Можно было бы просто сдекорировать UrlManager, но он опять без интерфейса. И т.п.
Vano
@samdark loc phpщный поможет посчитать?
Alexander
о, ну тогда офигенчик вообще
Alexey
Я б начал с линтера
Anton
далее когда уберу все дублирование query. Внедрить машину состояний. Где на каждый статус будет собственный хендлер
Alexander
@devium нет, он churn не умеет
Vano
а кто умеет?
Alexander
но тулз полно, по "git churn" ищи
Alexander
выбирай на вкус
Anton
в любом случае если не прибираться, то энтропия кода растет
Vano
принято
Vano
@symbios_zi что-то реальным говнищем пахнет в твоем текущем проекте... ))) Глаза видели, что брали?
Anton
проект с 2011 года
Alexander
> уберу все дублирование query не всё то дубль, что дублем кажется
Alexander
> Внедрить машину состояний. Где на каждый статус будет собственный хендлер Чую, CRM-ка :)
Anton
в сфере ЖКХ
Anton
да
Anton
ну такая система ведения заявок
Anton
она интересная, просто нужно прибираться
Vitaliy
Элементарно. Если принесли замысловатую вёрстку не на Bootstrap, то ActiveForm и LinkPager не подходит. Если нужны замысловатые таблицы с colspan и rowspan, то выбрасываем GridView. Если проектируем сложные сущности со вложенными объектами-значениями, то сильно перепиливаем ActiveRecord или меняем его на Doctrine. Если подключаем сторонние компоненты, работающие по PSR, то пишем адаптеры PSR. Если хотим делать фреймворконезависимые PSR-7 контроллеры, то нужно самому программировать трансформеры для запроса и ответа и адаптеры для контроллеров. Если хотим делать маршрутизацию по именам маршрутов, а не по именам контроллеров и экшенов, то нужно переписать фреймворковский UrlManager или заменить на другой. Но у него нет интерфейса, поэтому придётся наследоваться. Потом хотим добавить мультиязычность в адресе. Можно было бы просто сдекорировать UrlManager, но он опять без интерфейса. И т.п.
Дима, Вы закончили мастер класс, или заканчиваете по Ларавел. Там Eloquent был или доктрина?
Anton
жду вот технический спринт
Alexander
https://habrahabr.ru/post/351686/
Alexander
вот
Anton
ага читал
Alexander
это про реальность, а не про идеальные проекты в вакууме
Alexander
про реально успешные с точки зрения проекты, которые выстрелили частично за счёт того, что не делали идеально
Dmitry
Дима, Вы закончили мастер класс, или заканчиваете по Ларавел. Там Eloquent был или доктрина?
Eloquent, так как это мастер-класс по Laravel. Doctrine будет в мастер-классе по Symfony.
Alexander
Надо мастер-класс по Doctrine :)
Alexey
Элементарно. Если принесли замысловатую вёрстку не на Bootstrap, то ActiveForm и LinkPager не подходит. Если нужны замысловатые таблицы с colspan и rowspan, то выбрасываем GridView. Если проектируем сложные сущности со вложенными объектами-значениями, то сильно перепиливаем ActiveRecord или меняем его на Doctrine. Если подключаем сторонние компоненты, работающие по PSR, то пишем адаптеры PSR. Если хотим делать фреймворконезависимые PSR-7 контроллеры, то нужно самому программировать трансформеры для запроса и ответа и адаптеры для контроллеров. Если хотим делать маршрутизацию по именам маршрутов, а не по именам контроллеров и экшенов, то нужно переписать фреймворковский UrlManager или заменить на другой. Но у него нет интерфейса, поэтому придётся наследоваться. Потом хотим добавить мультиязычность в адресе. Можно было бы просто сдекорировать UrlManager, но он опять без интерфейса. И т.п.
Мультиязычность на стандартном менеджере делается легко
Alexander
отдельный
Anton
большинство проектов такие