Я согласен с вашим комментарием, но он лежит в другой плоскости.
Я намекал, что 1702 часа оргвопросов в месяц (размер команды х 46 — примерно как 9,5 человек фулл-тайм) это повод задуматься об эффективности данной модели. Например что-то придумать, чтобы не всю команду вовлекать в эти процессы.
Два выходных между спринтами и 5 "боевых" рабочих часов в день. Т.е. где-то 46 часов в месяц из 176 каждый разработчик не разрабатывает, а занимается оргвопросами. Страшно умножать это на количество разработчиков, но по-моему секрет вашего успеха не в эффективности распределения рабочего времени.
А когда я был маленьким было принято бить по рукам за прямые *QL запросы с клиента на сервер :) Инъекции, вот это всё.
Оказывается надо было просто заменить S на Graph.
Чем это вообще лучше простого SQL с экранированием?
Прочитал постановку задачи и не понял чем не угодили:
— Реализации обычных ESB — WSO2 или Mule — если это используется в другом приложении
— Zabbix, если это все ради мониторинга
Был какой-то анализ на тему взять готовое vs велосипед?
Сроки можно за скобками оставить — нагнал на фичу втрое больше людей и успел (если есть ресурсы).
Если вычитание из ожидаемой прибыли проекта 2*Х (для простоты — прибыль в часах) дает положительное число — сжимаем зубы и делаем.
Если отрицательное, допустим оно равно M, то смотрим:
1) Если М больше, чем уже потрачено человеко-часов на проект — закрываем проект.
2) Если М меньше — делаем проект и молимся*, чтобы второй такой фразы не было.
* на самом деле не молимся, а внимательно читаем ТЗ и анализируем риски.
Я правильно понял, что основная и единственная мотивация полностью переделать решение — команде разработки скучно и люди увольняются?
Т.е. организационные проблемы повлияли на архитектуру решения?
Т.е. бизнес еще и заплатил за эти развлекухи, но не получил практической пользы?
Человеку, который продал это бизнесу, надо идти в продажи, а не в разработку.
Считаем, что вам нужно не два инстанса по 100 и один 500 метров памяти, и не два по 600, а один на 700. Экономим на процессоре (и всем остальном кроме памяти), электричестве, аренде места в стойке.
А почему никто не пишет, что при разделении монолита тотально падает время отклика системы? Вызов, который ранее случался через стек за несколько тактов теперь передается аж по сети, да еще с сериализацией в текст (http же).
Также возможность горизонтально масштабировать случается в ущерб возможности вертикально.
Я с вами согласен при условии, что все участники процесса решили работать по самому махровому Waterfall какой есть. Привет ребятам из Agile-топиков.
Также в процессе произошла подмена понятий разработчик -> программист (в вашей интерпретации чуть ли не кодер).
В принципе ваша точка зрения понятна, вы четко обозначили свою роль и все риски переложили на других людей.
В целом выходит ситуация из анекдота «Сколько программистов нужно, чтобы вкрутить лампочку», когда, чтобы достать данные из БД в человеко-читаемый формат нужно минимум 4 человека.
Почему у BehaviorRegistry публичный внутренний map? Инкапсуляция не нужна?
Зачем вызывать add через sendTo? Чтобы выпендриться?
В целом получился Publisher-Subscriber, ну ок.
А ещё забыли реализовать пруд из условия и абсолютно всю часть взаимодействия с ним.
Я намекал, что 1702 часа оргвопросов в месяц (размер команды х 46 — примерно как 9,5 человек фулл-тайм) это повод задуматься об эффективности данной модели. Например что-то придумать, чтобы не всю команду вовлекать в эти процессы.
Два выходных между спринтами и 5 "боевых" рабочих часов в день. Т.е. где-то 46 часов в месяц из 176 каждый разработчик не разрабатывает, а занимается оргвопросами. Страшно умножать это на количество разработчиков, но по-моему секрет вашего успеха не в эффективности распределения рабочего времени.
Круто иметь два дополнительных выходных между спринтами.
Какая разница? Ну пусть будет MDX, а не SQL. Язык запросов и есть язык запросов.
А когда я был маленьким было принято бить по рукам за прямые *QL запросы с клиента на сервер :) Инъекции, вот это всё.
Оказывается надо было просто заменить S на Graph.
Чем это вообще лучше простого SQL с экранированием?
Правильность и оптимальность — это точно не про туториалы.
Никогда не понимал как люди что-то учат по туториалам или книгам. Дали задачу — запили или умри.
— Реализации обычных ESB — WSO2 или Mule — если это используется в другом приложении
— Zabbix, если это все ради мониторинга
Был какой-то анализ на тему взять готовое vs велосипед?
Сроки можно за скобками оставить — нагнал на фичу втрое больше людей и успел (если есть ресурсы).
Если вычитание из ожидаемой прибыли проекта 2*Х (для простоты — прибыль в часах) дает положительное число — сжимаем зубы и делаем.
Если отрицательное, допустим оно равно M, то смотрим:
1) Если М больше, чем уже потрачено человеко-часов на проект — закрываем проект.
2) Если М меньше — делаем проект и молимся*, чтобы второй такой фразы не было.
* на самом деле не молимся, а внимательно читаем ТЗ и анализируем риски.
Отвечу за автора: прошу за дополнительную фичу дополнительных денег.
А есть понимание, где заканчивается DWH и начинается MDM? Архитектурно, например.
Т.е. организационные проблемы повлияли на архитектуру решения?
Т.е. бизнес еще и заплатил за эти развлекухи, но не получил практической пользы?
Человеку, который продал это бизнесу, надо идти в продажи, а не в разработку.
Окей, уютные чатики для сотрудников сделали. А мониторинг трудозатрат для руководства где?
А почему никто не пишет, что при разделении монолита тотально падает время отклика системы? Вызов, который ранее случался через стек за несколько тактов теперь передается аж по сети, да еще с сериализацией в текст (http же).
Также возможность горизонтально масштабировать случается в ущерб возможности вертикально.
Также в процессе произошла подмена понятий разработчик -> программист (в вашей интерпретации чуть ли не кодер).
В принципе ваша точка зрения понятна, вы четко обозначили свою роль и все риски переложили на других людей.
В целом выходит ситуация из анекдота «Сколько программистов нужно, чтобы вкрутить лампочку», когда, чтобы достать данные из БД в человеко-читаемый формат нужно минимум 4 человека.