разве что сгенерированного кода)

разве что сгенерированного кода)

ну например ты описал ядро свертки 16x16 - уже 20 строк кода

надо сделать 10 сверток - уже 200 строк

надо потом еще все это дело автокореляционной функцией пройтись - еще держи

ну и т.д.

10К это конечно из области фантастики но 1К запросто

ну и посмотри на парсер DQL доктрины)

1к да, 10к тоже ок, но 1 миллион и при этом чтобы нельзя было разбить алгоритм

исходники доктрины не лучший объект вдохновения

это анрил

кстати да

композиция, декорация, SRP, open/close, маленькие специализированные объекты которые проще заменять на другую реализацию.

никто не будет переписывать трехлетний легаси, который уже в проде и стабилен

из-за этого рака в доктрине ее нереально поддерживать людям

когда можно поменять нужное место private -> protected

никто не будет переписывать трехлетний легаси, который уже в проде и стабилен

никто и не хочет этого, а вот поддерживать его оч хочется)

+ когда private ничем не аргументирован

никто не будет переписывать трехлетний легаси, который уже в проде и стабилен

окей, а что ты с этим легаси делаешь? ну то есть он развивается?

никто не будет переписывать трехлетний легаси, который уже в проде и стабилен

working effectivly with legacy code книженция

или "ну баги делаем и фиксим"

больше делаем

но иногда и фиксим

окей, а что ты с этим легаси делаешь? ну то есть он развивается?

не развивается, просто устоявшийся core

для других проектов

а как же правило бойскаута?

не развивается, просто устоявшийся core

просто не надо завязывать новый функционал на core и простой говногод очень легко рефакторится

а, ну так мертвым проектам действительно не надо ничего

если проект мейнтейнится, то код наоборот улучшаться должен

а как же правило бойскаута?

у нас скорее "разработка по пионерски"

http://cs5.pikabu.ru/images/big_size_comm/2015-08_4/1439816562176758161.jpg

у нас скорее "разработка по пионерски"

это как? наследие пионеров у нас на улицах - разруха и гавно)

http://cs5.pikabu.ru/images/big_size_comm/2015-08_4/1439816562176758161.jpg

хыхы

это как? наследие пионеров у нас на улицах - разруха и гавно)

увидел мусор на полянке - значит это мусорка

просто не надо завязывать новый функционал на core и простой говногод очень легко рефакторится

у тебя очень уж академический подход ко всему

было б смешно если б это не было так печально

у нас никто не хочет прикручивать доктрину, еще кучу всего, чтобы наплодить объектов, когда надо написать простой мигратор из одной таблички в другую

raw sql + тест

и поехали

еще и работать будет быстрее без всех этих нагромождений поверх

можно и без доктрины жить)

у нас никто не хочет прикручивать доктрину, еще кучу всего, чтобы наплодить объектов, когда надо написать простой мигратор из одной таблички в другую

для легаси проекта не нужна доктрина

я уже начинаю подумывать что она вообще нужна только для очень узкого класса проектов которые еще не доросли до CQRS + ES но уже перерасли AR/RowGAteway

еще и работать будет быстрее без всех этих нагромождений поверх

кастомные гидраторы и все работает быстро

это еще надо неслабо извернуться, чтобы реализовать на пхп insert по результам returning от update

и чтобы он работал не медленней одного raw-запроса

это еще надо неслабо извернуться, чтобы реализовать на пхп insert по результам returning от update

ээээээм.... звучит как извращение

и чтобы он работал не медленней одного raw-запроса

что мешает сделать raw запрос?

то что у тебя ORM в проекте не означает что ты должен ВСЕ делать через нее

главное что бы SQL был закрыт каким-то интерфейсом

например мой кейс: рекламный оффер. у него поменялись поля и изменения надо копить М времени и пушнуть в N других мест по апи

у апи рейт-лимиты

и оно rest

а при чем рест к доктрине?

поэтому надо копить и одним запросом все изменения конкретной сущности

у апи рейт-лимиты

redis для этого как бэ лучше подходит.

мое решение - insert по результам returning от update

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

и пушишь

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

http://www.kp.ru/f/4/image/64/97/119764.jpg

ночь с этим мужиком?

в рамочке и все такое.

не. просто сомнительная фотка за сомнительное решение

ну то есть сомнительное решение это не плохое решение

просто есть вопросы)

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

и пушишь

ну так это не доменная логика, это чисто инфраструктурные ограничения.

ERROR: S client not available

если к решению не смогут выдать хоть одно альтернативное, то это сомнительное решение)

sql-то я оборачиваю

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

да не надо пихать паттерны. Надо принципы пихать

или ты хочешь сказать что инкапсуляцию придумали нехорошие люди?

а Барбара лисков вообще была стервой со своим принципом подстановки?

и то что Страуступ жалеет что в C++ добавили protected потому что "эх а как бы у людей подгорало бы если б я это обрезал"

+- нормально и тесты проходят @ го в прод

+- нормально и тесты проходят @ го в прод

не ну тут не спорю)

я уже давно прогнулся под бизнес(

платили бы за ковыряние палкой в земле - ковырял бы палкой, а за полное соответсвие SOLID не платят(

+- нормально и тесты проходят @ го в прод

*ручные тесты

я уже давно прогнулся под бизнес(

технический долг и бизнес идут рука обруку. Но ты должен знать когда надо его снижать

зачастую проще и дешевле железа подкинуть

хотя не всегда

бизнесу пофиг на твои SOLID

и SOLID это не о железе

тут ты свои часы жгешь на поддержку хренового кода

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

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

ну если ты жжешь часы на сингелтоны - то да.... лучше не надо

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

хотя кто-то советует всегда выкидывать прототип продукта и писать заново, когда идея подтвердилась

так принцип ж простой, если это сэкономит денег, то это надо, если не сэкономит, то не надо

твоя задача понять какой у тебя случай

хотя кто-то советует всегда выкидывать прототип продукта и писать заново, когда идея подтвердилась

не надо так делать

хотя кто-то советует всегда выкидывать прототип продукта и писать заново, когда идея подтвердилась

это норм подход когда ты делаешь R&D

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

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

сегодня прототип, завтра продакшен

сегодня прототип, завтра продакшен

сегодня продакшен, завтра продакшен - у меня так

а как же эксперементы?

сегодня продакшен, завтра продакшен - у меня так

сегодня легаси, завтра легаси

а сколько стоит баг?

лояльные бета-пользователи на свой страх и риск пользуют бесплатно