В приведенном примере, скорее всего, начальная реализация OrderService подразумевала не просто пустой ответ, а результат работы сервиса (order_id, notification_result, shipped_result).
С переходом на асинхронные сообщения, мы также переходим и на асинхронные ответы. В случае когда формат ответа нужно сохранить, мы должны будем не переписывать старый контроллер, а добавить новый. После чего нужно ждать когда все кто использовал этот контроллер перейдут на новую асинхронную версию.
И как быть, если наши партнеры не особо то и хотят этим заниматься? Их все устраивало раньше, они отправляли запрос и получали ответ, а теперь им надо городить какие то сокеты, пинги, лонгпулинг или что то еще.
А в чем проблема переопределения стилей? Я ведь могу условно обернуть Bootstrap компонент в какой то .class-wrapper и переопределить все что внутри него через условный .class-wrapper .btn ? Более того эти библиотеки ведь дают как то настраивать тему.
Вы не думали поднять публичную демо версию, чтобы мы все могли зайти и протестировать ее? Собрали бы таким образом фидбеки и контакты тех кому было интересно.
Ну потому что задачу не просто положили в спринт, а весьма осознано и обдумано положили именно в этот спринт а не какой-то другой. Задача команды сперва убрать все риски по провалу спринта, а потом уже делать все остальное. Ваше условие, что спринтовую вы все ровно успеете, оно имеет какую то вероятность. И никто не хочет рисковать, чтобы потом на ретро не рассказывать, о том что вы рискнули, но не получилось, и поэтому спринт провален.
Поясните, что влияет на вашу оценку задачи сегодня, и через неделю? Я понимаю когда за полгода в проекте поменяется кодовая база и потребуется переоценка некоторых задач. Но даже эта переоценка не поменяется ведь у вас через неделю? Вы что, разное время задачи указываете с поправкой на то, что вы злой будете, или не будете? То что вы про контекст подготовки и переключения написали, это должно учитываться в оценке изначально.
Как вы с коллегами работаете в команде? Допустим вы оценили задачу в 8 часов, а ваш коллега оценивает эту же задачу в 4 часа. Что после этого происходит?
То что вы говорите, о том что бизнесу неважно время доставки фич, это не так. Бизнесу очень важно время появления той или иной фичи в продукте, я бы даже сказал жизненно важно, потому что рынок решает. Представьте что у вашего конкурента вышел релиз с новой важной фичей, а у вас аналогичная фича появится примерно где то в сумме в пол года в вперемешку со всем остальным. Вы не боитесь что за эти пол года ваши клиенты уйдут к вашему конкуренту из-за как раз той самой новой фичи, которая у него уже есть, а у вас появится непонятно когда? Выбирать приоритеты задач это на самом деле отдельное искусство. И можно очень сильно с этим накосячить или наоборот очень сильно преуспеть.
Я совсем вас не понял. Вы задачу оцениваете перед тем как ее делать? Как может быть такое что, сейчас вы задачу оценили в 1 час, а через месяц вы оцените эту же задачу в 7 дней? Разработчики всегда оценивают задачи с учетом какого то запаса времени, но это не 7 дней к задаче на 1 час. Именно поэтому многие уходят от оценки по времени, в оценку в сторипоинтах. Именно поэтому есть такие встречи как скрам покер.
Задача в беклоге уже лежит оцененная. Мы берем в спринт задачи которые точно успеем сделать. Если вы способны вырабатывать в спринт 40 часов, то никто не возьмет на вас задач на 80 часов. Если вы не успеваете в ваши же оценки, то это лично ваша проблема. Это говорит о том что у вас какая то проблема с оценкой. Оценили задачу в 1 час, то и сделайте ее в 1 час. Сегодня или завтра, или через месяц.
Помимо этой задачи в беклоге есть еще 100500 задач. И все они нужны бизнесу, иначе их бы не было в беклоге. И приоритет задач не может управляться желанием исполнителей, иначе мы получим ситуацию где все делают только то что хотят делать, а то что нужно бизнесу будет сдвигаться на потом по различным причинам. Парадокс, бизнес платит зарплату, за то что разработчики делают то что они хотят делать прямо сейчас, а не то что нужно бизнесу прямо сейчас.
А разве Sprint Retrospective не является тем самым "Люди и взаимодействие важнее процессов и инструментов" ? Ведь как раз на этой встрече и нужно поднять вопрос о том как люди взаимодействовали, какие инструменты нужны или не нужны. Именно тут надо все это выяснять и фиксировать.
Допустим команда решила что общается в slack, но один из людей будет постоянно общаться со всеми в telegram. Он же не может ссылаться на то что у нас Agile и люди и взаимодействие важнее процессов и инструментов?
Идея проста, бежим 100 метровку по определенной дороге, и никто не должен вам на эту дорогу добавлять препятствий или ям. Вы заранее видите весь участок в 2 недели. Не должно быть такого, чтобы вам в спринт постоянно прилетали новые задачи, которые двигают все остальные. Если у вас и бывает очень много багов с прода, то спринт планируется с запасом времени под такие баги. Условно у вас забито 8 дней задачами и 2 дня под возможные баги с прода. Если вы выполнили все задачи из спринта, то это никогда не означает что оставшееся время вы ничего не делаете.
А что за работа такая где вы сами определяете что бизнесу нужно прямо сейчас? То есть как это вы решили что бизнесу задача 23 важнее чем задача 12? Ну ок, если есть какие то мысли по поводу задачи 23, ну пометьте себе в todo и продолжайте задачу 12. Как правило спринт имеет цель, которая согласована с продукт оунером. И он ожидает что вы сделаете задачу 12, и на демо покажите именно ее, а не задачу 23. Согласитесь было бы странно, если бы он пришел посмотреть на задачу 12, а вы ему говорите что у вас там была идея и вы сделали задачу 23 вместо задачи 12. Если ваша идея позволит вам сделать задачу 23 за 1 день, то какая разница, сегодня это или через неделю?
С релизами не всегда все однозначно. Какие то задачи могут уходить в релиз по готовности, а какие то с фичатогл флагами. Одна большая фича может по частям добавляться в релизы, а доступной для всех пользователей она может стать намного позже. И нет смысла ждать окончания спринта, если задача уже сделана, и ничего не мешает отдать ее в прод. Релизы это не всегда конец спринта.
Почему же не индустрия достижений? Вполне также в нашей отрасли люди пытаются получить различного рода достижения. К примеру получать различные сертификаты от вендоров сдавая экзамены, или скажем выступать на каких то конференциях. Программисты борются за различные ачифки на codeforces или рейтинге стековервлоу. Да даже тут на Хабре люди стремятся к поднятию своего рейтинга чтобы как то отличаться от всех других в отрасли.
Вот "качественные продукты" это вполне конкретные метрики которые надо улучшать. И может быть так что у вас не будет хватать компетенции для улучшения этих метрик. Тем более, для того чтобы улучшать эти метрики, необходимо знать подходящие для этого инструменты. Абстрактный пример на дровосеках. Вот рубят они топорами лес. А тут на рынке появляется бензопила. Один из них скажет что развиваться не нужно, можно продолжать рубить лес топорами и это автоматически будет прокачивать людей в том, чтобы работать топором еще быстрее и лучше, а другой пойдет и научиться работать с бензопилой. В итоге рынок порешает кто из них будет востребован завтра а кто нет. А бизнес потихоньку начнет переходить на бензопилы. Мы в этом плане ни чем не отличаемся от дровосеков.
А вот не абстрактный пример, очень большое количество сайтов написано с использованием jquery, но при этом сейчас он нужен все меньше. Надо ли развиваться фронтендеру чтобы уйти с jquery или можно оставаться на нем? Работая каждый день с jquery он ведь не будет развиваться во все эти нужные сейчас реактивные технологии? Конечно он может не развиваться и зарабатывать свой хлеб на jquery еще очень долго, но он явно будет востребован все меньше и меньше, как тот лесоруб с топором. И вот когда в какой то момент времени, бизнес придет с требованием сделать "качественный продукт", то его компетенций только с jquery может уже не хватить.
Вы правы когда говорите что люди не обязаны развиваться, но развиваться обязаны все те кто хочет быть лучшим среди остальных. Если вы хотите карьерный рост, и вырасти с junior до СТО, то это просто не возможно без развития в личное время. Работая ежедневно на работе, вы не получите все те навыки которые нужны для этих позиций. Лошадь работала в колхозе лучше всех, но председателем так и не стала.
Ну если боишься травм то лучше не идти в спортсмены изначально. Я же говорю вам про уровень. Вы вполне можете быть спортсменом местного разлива и остановиться в развитии на уровне школьного тренера. Получать свои деньги и делать свою работу. И вы можете пытаться стать олимпийским чемпионом, где и усилий надо больше, и риски выше, и деньги и слава совсем другие.
Не очень то это и похоже на каждодневную работу для очень многих людей. Опыт в 10 лет не всегда означает то что человек все 10 лет развивался. Вполне может оказаться так что это просто опыт в 1 год повторенный 10 раз.
Если профессиональный спортсмен не хочет стать олимпийским чемпионом и не стремиться к этому, то какого уровня он спортсмен? Вполне нормально прикладывать максимальные усилия на то чтобы стать лучшим только в одной сфере и в одном направлении. Не нормально когда стремишься стать олимпийским чемпионом по всем видам спорта сразу.
Используем composer в Битрикс проектах очень давно, и никогда такие проблемы как вы описали не испытывали. Положить vendor в гит такая себе идея. Этим вы убиваете вообще весь смысл использования composer. Потом в добавок будете наблюдать кучу изменений vendor в мержреквестах.
На сколько я понял, вопрос был не про local, а про то что Битрикс сам использует composer. И вам надо ваш composer смержить с composer битрикса, чтобы вы не получили конфликт версий пересекающихся пакетов.
Более того вы размещаете vendor в публичной части сайта. Кто знает какой пакет вы там затяните, злоумышленник может получить бекдор, через публичный путь сайт.рф/local/vendor/mypackage/backdoor.php
Мантра стала классикой не просто так, а по вполне объективным причинам. Когда вы начнете выяснять "а кто виновен в баге", то вы можете столкнуться с тем что все начнут указывать друг на друга. Программист скажет это тестировщик плохо тестировал, тестировщик скажет это плохо код ревью провели, менеджер скажет что это тимлид виноват в том что нанял такого программиста, тимлид скажет что это архитектор так спроектировал систему. Архитектор скажет что виноват прошлый разработчик который уже уволился и т.д. И для чего все это делать? чтобы в итоге что? Какой итог вы хотите получить? Хотите чтобы в команде все друг друга ненавидели или хотите растерять всю экспертизу при высокой текучке кадров?
Мы с вами говорим о сферическом коне в вакууме. Цена бага в коде для космического корабля, и цена бага на сайте регионального салона красоты очень разная. Как и квалификация разработчиков которые нужны для этой работы. Плюс, надо понимать, какие стадии проходит код до выкладки в прод. А есть ревью? Почему баг не нашли там? А есть автотесты? Почему они не показали что есть баг? А есть отдел тестирования? почему он не нашел этот баг? А есть система мониторинга? почему из нее не прилетел алерт, чтобы быстро пофиксить баг? Да и даже если все это есть, то все ровно баг может оказаться в проде. Потому что просто невозможно покрыть тестами все возможные кейсы. Всегда есть вероятность получить баг в коде, хоть у джуна, хоть у сеньора.
Если в проекте ни как не работают с качеством, то как вы можете уволить разработчика за баг? Тем более баг ведь может быть вообще не в вашем коде, а в какой то библиотеке или фреймверке, в конце концов баг может быть даже в компиляторе. Посмотрите к примеру как релизят языки программирования, фреймверки или операционные системы. Там же постоянно после релиза определенной версии, в последующем релизят патчи с исправлениями багов или проблем с секьюрностью. И это вполне нормально, и никого за это не увольняют.
Увольнять за баги нужно только в том случае, если этот баг вылился в какие то серьезные проблемы для компании, и при этом вина уволенного для всех очевидна и неоспорима. Во всех остальных случаях разбираться "а кто виновен в баге", не очень продуктивно для команды. Лучше поставить вопрос по другому "как нам всем вместе сделать так, чтобы багов в проде больше никогда не было". Собрать все предложения, и уже отсюда двигаться в сторону увеличения качества.
Вы правы, я хотел указать именно на то что в статье мало написано про контексты. В случае с историческими данными чаще всего делают два разных Entity, но когда правила меняются часто, то это приводит к огромному количеству классов, с которыми тяжелее работать чем с одним. Тут надо искать компромиссы, а не слепо следовать лучшим практикам.
Я в целом знаю ответы на эти вопросы, мне лишь хотелось указать на то что вы рассматриваете прям очень простые кейсы валидации. Как в том знаменитом примере когда единорог без рога является лошадью. Тема ведь далеко не новая.
Для истории чаще всего делают два разных класса Order, было бы неплохо дописать в статье про это. С отчетами обычно все проще, потому что там SQL выборки которые нет смысла превращать в объекты.
Когда я говорил про бизнес логику которая не зависит от Entity я имел ввиду всякие методы по типу canOrderChangeStatus() или про методы isValid(). То есть не про простые кейсы что email это действительно email, и что у единорога есть рог, а про что то сложное, что требует каких то сложных зависимостей.
В приведенном примере, скорее всего, начальная реализация OrderService подразумевала не просто пустой ответ, а результат работы сервиса (order_id, notification_result, shipped_result).
С переходом на асинхронные сообщения, мы также переходим и на асинхронные ответы. В случае когда формат ответа нужно сохранить, мы должны будем не переписывать старый контроллер, а добавить новый. После чего нужно ждать когда все кто использовал этот контроллер перейдут на новую асинхронную версию.
И как быть, если наши партнеры не особо то и хотят этим заниматься? Их все устраивало раньше, они отправляли запрос и получали ответ, а теперь им надо городить какие то сокеты, пинги, лонгпулинг или что то еще.
А в чем проблема переопределения стилей? Я ведь могу условно обернуть Bootstrap компонент в какой то .class-wrapper и переопределить все что внутри него через условный .class-wrapper .btn ? Более того эти библиотеки ведь дают как то настраивать тему.
Вы просто переписали часть документации апи платформы в статью на хабр?
Вы не думали поднять публичную демо версию, чтобы мы все могли зайти и протестировать ее? Собрали бы таким образом фидбеки и контакты тех кому было интересно.
Ну потому что задачу не просто положили в спринт, а весьма осознано и обдумано положили именно в этот спринт а не какой-то другой. Задача команды сперва убрать все риски по провалу спринта, а потом уже делать все остальное. Ваше условие, что спринтовую вы все ровно успеете, оно имеет какую то вероятность. И никто не хочет рисковать, чтобы потом на ретро не рассказывать, о том что вы рискнули, но не получилось, и поэтому спринт провален.
Поясните, что влияет на вашу оценку задачи сегодня, и через неделю? Я понимаю когда за полгода в проекте поменяется кодовая база и потребуется переоценка некоторых задач. Но даже эта переоценка не поменяется ведь у вас через неделю? Вы что, разное время задачи указываете с поправкой на то, что вы злой будете, или не будете? То что вы про контекст подготовки и переключения написали, это должно учитываться в оценке изначально.
Как вы с коллегами работаете в команде? Допустим вы оценили задачу в 8 часов, а ваш коллега оценивает эту же задачу в 4 часа. Что после этого происходит?
То что вы говорите, о том что бизнесу неважно время доставки фич, это не так. Бизнесу очень важно время появления той или иной фичи в продукте, я бы даже сказал жизненно важно, потому что рынок решает. Представьте что у вашего конкурента вышел релиз с новой важной фичей, а у вас аналогичная фича появится примерно где то в сумме в пол года в вперемешку со всем остальным. Вы не боитесь что за эти пол года ваши клиенты уйдут к вашему конкуренту из-за как раз той самой новой фичи, которая у него уже есть, а у вас появится непонятно когда? Выбирать приоритеты задач это на самом деле отдельное искусство. И можно очень сильно с этим накосячить или наоборот очень сильно преуспеть.
Я совсем вас не понял. Вы задачу оцениваете перед тем как ее делать? Как может быть такое что, сейчас вы задачу оценили в 1 час, а через месяц вы оцените эту же задачу в 7 дней? Разработчики всегда оценивают задачи с учетом какого то запаса времени, но это не 7 дней к задаче на 1 час. Именно поэтому многие уходят от оценки по времени, в оценку в сторипоинтах. Именно поэтому есть такие встречи как скрам покер.
Задача в беклоге уже лежит оцененная. Мы берем в спринт задачи которые точно успеем сделать. Если вы способны вырабатывать в спринт 40 часов, то никто не возьмет на вас задач на 80 часов. Если вы не успеваете в ваши же оценки, то это лично ваша проблема. Это говорит о том что у вас какая то проблема с оценкой. Оценили задачу в 1 час, то и сделайте ее в 1 час. Сегодня или завтра, или через месяц.
Помимо этой задачи в беклоге есть еще 100500 задач. И все они нужны бизнесу, иначе их бы не было в беклоге. И приоритет задач не может управляться желанием исполнителей, иначе мы получим ситуацию где все делают только то что хотят делать, а то что нужно бизнесу будет сдвигаться на потом по различным причинам. Парадокс, бизнес платит зарплату, за то что разработчики делают то что они хотят делать прямо сейчас, а не то что нужно бизнесу прямо сейчас.
А разве Sprint Retrospective не является тем самым "Люди и взаимодействие важнее процессов и инструментов" ? Ведь как раз на этой встрече и нужно поднять вопрос о том как люди взаимодействовали, какие инструменты нужны или не нужны. Именно тут надо все это выяснять и фиксировать.
Допустим команда решила что общается в slack, но один из людей будет постоянно общаться со всеми в telegram. Он же не может ссылаться на то что у нас Agile и люди и взаимодействие важнее процессов и инструментов?
Идея проста, бежим 100 метровку по определенной дороге, и никто не должен вам на эту дорогу добавлять препятствий или ям. Вы заранее видите весь участок в 2 недели. Не должно быть такого, чтобы вам в спринт постоянно прилетали новые задачи, которые двигают все остальные. Если у вас и бывает очень много багов с прода, то спринт планируется с запасом времени под такие баги. Условно у вас забито 8 дней задачами и 2 дня под возможные баги с прода. Если вы выполнили все задачи из спринта, то это никогда не означает что оставшееся время вы ничего не делаете.
А что за работа такая где вы сами определяете что бизнесу нужно прямо сейчас? То есть как это вы решили что бизнесу задача 23 важнее чем задача 12? Ну ок, если есть какие то мысли по поводу задачи 23, ну пометьте себе в todo и продолжайте задачу 12. Как правило спринт имеет цель, которая согласована с продукт оунером. И он ожидает что вы сделаете задачу 12, и на демо покажите именно ее, а не задачу 23. Согласитесь было бы странно, если бы он пришел посмотреть на задачу 12, а вы ему говорите что у вас там была идея и вы сделали задачу 23 вместо задачи 12. Если ваша идея позволит вам сделать задачу 23 за 1 день, то какая разница, сегодня это или через неделю?
С релизами не всегда все однозначно. Какие то задачи могут уходить в релиз по готовности, а какие то с фичатогл флагами. Одна большая фича может по частям добавляться в релизы, а доступной для всех пользователей она может стать намного позже. И нет смысла ждать окончания спринта, если задача уже сделана, и ничего не мешает отдать ее в прод. Релизы это не всегда конец спринта.
Вот уже и вышел PHP 8.1. Скажите, как с ним поменялась ваша оптимизация?
Почему же не индустрия достижений? Вполне также в нашей отрасли люди пытаются получить различного рода достижения. К примеру получать различные сертификаты от вендоров сдавая экзамены, или скажем выступать на каких то конференциях. Программисты борются за различные ачифки на codeforces или рейтинге стековервлоу. Да даже тут на Хабре люди стремятся к поднятию своего рейтинга чтобы как то отличаться от всех других в отрасли.
Вот "качественные продукты" это вполне конкретные метрики которые надо улучшать. И может быть так что у вас не будет хватать компетенции для улучшения этих метрик. Тем более, для того чтобы улучшать эти метрики, необходимо знать подходящие для этого инструменты. Абстрактный пример на дровосеках. Вот рубят они топорами лес. А тут на рынке появляется бензопила. Один из них скажет что развиваться не нужно, можно продолжать рубить лес топорами и это автоматически будет прокачивать людей в том, чтобы работать топором еще быстрее и лучше, а другой пойдет и научиться работать с бензопилой. В итоге рынок порешает кто из них будет востребован завтра а кто нет. А бизнес потихоньку начнет переходить на бензопилы. Мы в этом плане ни чем не отличаемся от дровосеков.
А вот не абстрактный пример, очень большое количество сайтов написано с использованием jquery, но при этом сейчас он нужен все меньше. Надо ли развиваться фронтендеру чтобы уйти с jquery или можно оставаться на нем? Работая каждый день с jquery он ведь не будет развиваться во все эти нужные сейчас реактивные технологии? Конечно он может не развиваться и зарабатывать свой хлеб на jquery еще очень долго, но он явно будет востребован все меньше и меньше, как тот лесоруб с топором. И вот когда в какой то момент времени, бизнес придет с требованием сделать "качественный продукт", то его компетенций только с jquery может уже не хватить.
Вы правы когда говорите что люди не обязаны развиваться, но развиваться обязаны все те кто хочет быть лучшим среди остальных. Если вы хотите карьерный рост, и вырасти с junior до СТО, то это просто не возможно без развития в личное время. Работая ежедневно на работе, вы не получите все те навыки которые нужны для этих позиций. Лошадь работала в колхозе лучше всех, но председателем так и не стала.
Ну если боишься травм то лучше не идти в спортсмены изначально. Я же говорю вам про уровень. Вы вполне можете быть спортсменом местного разлива и остановиться в развитии на уровне школьного тренера. Получать свои деньги и делать свою работу. И вы можете пытаться стать олимпийским чемпионом, где и усилий надо больше, и риски выше, и деньги и слава совсем другие.
Не очень то это и похоже на каждодневную работу для очень многих людей. Опыт в 10 лет не всегда означает то что человек все 10 лет развивался. Вполне может оказаться так что это просто опыт в 1 год повторенный 10 раз.
Если профессиональный спортсмен не хочет стать олимпийским чемпионом и не стремиться к этому, то какого уровня он спортсмен? Вполне нормально прикладывать максимальные усилия на то чтобы стать лучшим только в одной сфере и в одном направлении. Не нормально когда стремишься стать олимпийским чемпионом по всем видам спорта сразу.
Как говорится можно иметь опыт 10 лет, а можно иметь опыт 1 год 10 раз и это не одно и тоже.
Используем composer в Битрикс проектах очень давно, и никогда такие проблемы как вы описали не испытывали. Положить vendor в гит такая себе идея. Этим вы убиваете вообще весь смысл использования composer. Потом в добавок будете наблюдать кучу изменений vendor в мержреквестах.
На сколько я понял, вопрос был не про local, а про то что Битрикс сам использует composer. И вам надо ваш composer смержить с composer битрикса, чтобы вы не получили конфликт версий пересекающихся пакетов.
Более того вы размещаете vendor в публичной части сайта. Кто знает какой пакет вы там затяните, злоумышленник может получить бекдор, через публичный путь сайт.рф/local/vendor/mypackage/backdoor.php
Мантра стала классикой не просто так, а по вполне объективным причинам. Когда вы начнете выяснять "а кто виновен в баге", то вы можете столкнуться с тем что все начнут указывать друг на друга. Программист скажет это тестировщик плохо тестировал, тестировщик скажет это плохо код ревью провели, менеджер скажет что это тимлид виноват в том что нанял такого программиста, тимлид скажет что это архитектор так спроектировал систему. Архитектор скажет что виноват прошлый разработчик который уже уволился и т.д. И для чего все это делать? чтобы в итоге что? Какой итог вы хотите получить? Хотите чтобы в команде все друг друга ненавидели или хотите растерять всю экспертизу при высокой текучке кадров?
Мы с вами говорим о сферическом коне в вакууме. Цена бага в коде для космического корабля, и цена бага на сайте регионального салона красоты очень разная. Как и квалификация разработчиков которые нужны для этой работы. Плюс, надо понимать, какие стадии проходит код до выкладки в прод. А есть ревью? Почему баг не нашли там? А есть автотесты? Почему они не показали что есть баг? А есть отдел тестирования? почему он не нашел этот баг? А есть система мониторинга? почему из нее не прилетел алерт, чтобы быстро пофиксить баг? Да и даже если все это есть, то все ровно баг может оказаться в проде. Потому что просто невозможно покрыть тестами все возможные кейсы. Всегда есть вероятность получить баг в коде, хоть у джуна, хоть у сеньора.
Если в проекте ни как не работают с качеством, то как вы можете уволить разработчика за баг? Тем более баг ведь может быть вообще не в вашем коде, а в какой то библиотеке или фреймверке, в конце концов баг может быть даже в компиляторе. Посмотрите к примеру как релизят языки программирования, фреймверки или операционные системы. Там же постоянно после релиза определенной версии, в последующем релизят патчи с исправлениями багов или проблем с секьюрностью. И это вполне нормально, и никого за это не увольняют.
Увольнять за баги нужно только в том случае, если этот баг вылился в какие то серьезные проблемы для компании, и при этом вина уволенного для всех очевидна и неоспорима. Во всех остальных случаях разбираться "а кто виновен в баге", не очень продуктивно для команды. Лучше поставить вопрос по другому "как нам всем вместе сделать так, чтобы багов в проде больше никогда не было". Собрать все предложения, и уже отсюда двигаться в сторону увеличения качества.
Я в целом знаю ответы на эти вопросы, мне лишь хотелось указать на то что вы рассматриваете прям очень простые кейсы валидации. Как в том знаменитом примере когда единорог без рога является лошадью. Тема ведь далеко не новая.
Для истории чаще всего делают два разных класса Order, было бы неплохо дописать в статье про это. С отчетами обычно все проще, потому что там SQL выборки которые нет смысла превращать в объекты.
Когда я говорил про бизнес логику которая не зависит от Entity я имел ввиду всякие методы по типу canOrderChangeStatus() или про методы isValid(). То есть не про простые кейсы что email это действительно email, и что у единорога есть рог, а про что то сложное, что требует каких то сложных зависимостей.
Видео действительно классное, спасибо за него.