Если проводить аналогию с базами то, в том же кролике есть такое понятие как virtual host. И как раз брокер можно шарить, как и СУБД. А вот очереди и виртуальный хост нежелательно, так же как и бд с таблицами.
Спасибо интересная тема. Для нас больная тема, большая логика проекта хранится в хранимых процедурах. А почему выбран кастомный подход работы с гитом? есть же готовые решения версионирования в visual studio data tools и dbforge. Зачем постоянно создавать новый файл на alter table, если можно хранить только create, а его дифф генерировать в alter?
Разработчики стали счастливыми после прихода devops? Мне кажется что у них появилось больше работы с гитом. Нет сопротивление от них, что раньше было проще выводить в ручном режиме?
Не публиковали свой пайплайн в открытые источники? Интересно посмотреть на скрипт сборки tar файла
Спасибо за вопрос. Вызывать Use case стоит напрямую из Controllers, как отображено на схеме. Который может быть в логическом слое представления. Но как отображено в схеме у Microsoft, Controllers может быть в физической сборке фреймворка, рядом с Middlewares и DI контейнером.
Спасибо за комментарий. Это мнение которое основывается на множество источников. Действительно не объяснил в чем суть про python. Тут хотелось сделать акцент на python, как язык с большой популярность основывающийся на простоте. Поэтому дернул от-туда пару принципов. Возможно стоило больше это пояснить в статье
С перечисленными пунктами в ТЗ интересно, полезно. Но с их реализацией есть вопросы. Как уже сказали описать контракты и схемы БД в ручную требуется время, при этом в момент разработки они чаще всего меняются. Поэтому эти пункты должны лежать ближе к коду, это позволит разработчику поправить их, при реализации. Мы генерируем схему БД и OpenAPI из кода.
Интересно по пункту со поведенческой схемой, у вас достаточно это программистам? А схема компонентов? А сценарии(UseCase) в виде блок-схем?
Все в итоге свелось к "здравый смысл" во время груминга. Т.е. это хорошо если разработчики на момент груминга это заметят и обсудят. А может получиться так, что собрались обсуждать ТЗ, а всем все ясно, и формат данных так и не обсудили. Т.е. груминг не решает полностью проблему, хоть и помогает ее минимизировать.
Если в команде началась игра "Переложи проблему на другого" то тут явно проблемы. Аналитик должен вовремя получить обратную связь по ТЗ, во вторник при разработке или в среду от тестировщика. А дальше скорректировать ТЗ и оповестить исполнителей.
Так же тестировщик должен тестировать фронт и бэк отдельно. Тогда бы сам тестировщик заметил пробел в ТЗ и невозможность тестировать бэк
Вполне возможно что бизнес все равно больше заработал чем заплатил за этот рефакторинг. Он в процессе этих "заплаток" мог легко добавить задачу по новой фиче, которую надо срочно сделать как у конкурента, что бы заработать большие деньги. У него не было рисков, что команда, которая делает рефакторинг, распадется и после нее ничего не останется от нового проекта. И из закона убывающей предельнойполезности, возможно первые заплатки принесли уже нужную выгоду по проекту в первый месяц рефакторинга и 80% багов были устранены и издержки стали минимальны. А весь остальной год бизнес платил за рефакторинг из денег, которые он получил за первые заплатки.
Почему чужие деньги? Бывает он закладывает свой дом и свою машину, что бы вложиться в идею. А потом живет на съемной квартире за городом и добирается на маршрутке (вот и говонкод)
Если проводить аналогию с базами то, в том же кролике есть такое понятие как virtual host. И как раз брокер можно шарить, как и СУБД. А вот очереди и виртуальный хост нежелательно, так же как и бд с таблицами.
Спасибо интересная тема. Для нас больная тема, большая логика проекта хранится в хранимых процедурах. А почему выбран кастомный подход работы с гитом? есть же готовые решения версионирования в visual studio data tools и dbforge. Зачем постоянно создавать новый файл на alter table, если можно хранить только create, а его дифф генерировать в alter?
Разработчики стали счастливыми после прихода devops? Мне кажется что у них появилось больше работы с гитом. Нет сопротивление от них, что раньше было проще выводить в ручном режиме?
Не публиковали свой пайплайн в открытые источники? Интересно посмотреть на скрипт сборки tar файла
Спасибо за вопрос. Вызывать Use case стоит напрямую из Controllers, как отображено на схеме. Который может быть в логическом слое представления. Но как отображено в схеме у Microsoft, Controllers может быть в физической сборке фреймворка, рядом с Middlewares и DI контейнером.
Спасибо за комментарий. Это мнение которое основывается на множество источников. Действительно не объяснил в чем суть про python. Тут хотелось сделать акцент на python, как язык с большой популярность основывающийся на простоте. Поэтому дернул от-туда пару принципов. Возможно стоило больше это пояснить в статье
С перечисленными пунктами в ТЗ интересно, полезно. Но с их реализацией есть вопросы. Как уже сказали описать контракты и схемы БД в ручную требуется время, при этом в момент разработки они чаще всего меняются. Поэтому эти пункты должны лежать ближе к коду, это позволит разработчику поправить их, при реализации. Мы генерируем схему БД и OpenAPI из кода.
Интересно по пункту со поведенческой схемой, у вас достаточно это программистам? А схема компонентов? А сценарии(UseCase) в виде блок-схем?
Все в итоге свелось к "здравый смысл" во время груминга. Т.е. это хорошо если разработчики на момент груминга это заметят и обсудят. А может получиться так, что собрались обсуждать ТЗ, а всем все ясно, и формат данных так и не обсудили. Т.е. груминг не решает полностью проблему, хоть и помогает ее минимизировать.
Если в команде началась игра "Переложи проблему на другого" то тут явно проблемы. Аналитик должен вовремя получить обратную связь по ТЗ, во вторник при разработке или в среду от тестировщика. А дальше скорректировать ТЗ и оповестить исполнителей.
Так же тестировщик должен тестировать фронт и бэк отдельно. Тогда бы сам тестировщик заметил пробел в ТЗ и невозможность тестировать бэк
Вполне возможно что бизнес все равно больше заработал чем заплатил за этот рефакторинг. Он в процессе этих "заплаток" мог легко добавить задачу по новой фиче, которую надо срочно сделать как у конкурента, что бы заработать большие деньги. У него не было рисков, что команда, которая делает рефакторинг, распадется и после нее ничего не останется от нового проекта. И из закона убывающей предельной полезности, возможно первые заплатки принесли уже нужную выгоду по проекту в первый месяц рефакторинга и 80% багов были устранены и издержки стали минимальны. А весь остальной год бизнес платил за рефакторинг из денег, которые он получил за первые заплатки.
Почему чужие деньги? Бывает он закладывает свой дом и свою машину, что бы вложиться в идею. А потом живет на съемной квартире за городом и добирается на маршрутке (вот и говонкод)