Комментарии 7
>5. Мы принимаем архитектурные решения настолько поздно, насколько возможно
А что вы понимаете под архитектурными решениями?
А что вы понимаете под архитектурными решениями?
Любые решения о создании дополнительной абстракции/слоя/схемы взаимодействия между компонентами/слоями.
Я представляю в чем профит откладывания принятия решения выбора субд
А в чем профит откладывания создания доп абстракции (ну в пределах разумного, не знаю где провести эту грань)?
А в чем профит откладывания создания доп абстракции (ну в пределах разумного, не знаю где провести эту грань)?
Профит в том, чтобы не спешить добавлять в систему ограничения, если можно обойтись без них.
Выбранный фреймворк/шаблон/инструмент это ограничение, которое при изменении условий (требований) может стать проблемой (перестало подходить, надо рефакторить).
Отсюда вывод, что если пока окончательное решение можно не принимать, то и не нужно торопиться его принимать.
Выбранный фреймворк/шаблон/инструмент это ограничение, которое при изменении условий (требований) может стать проблемой (перестало подходить, надо рефакторить).
Отсюда вывод, что если пока окончательное решение можно не принимать, то и не нужно торопиться его принимать.
Абстракция и «архитектурное решение» — все же разные понятия. Второе напрямую может зависеть от первого, но не наоборот.
Немного офтопа. Если я правильно понимаю, ваша команда работает над частью проекта, то есть над определенным модулем, библиотекой и пр. Мне интересно знать, ваша команда имеет доступ к коду всего проекта? Если нет, то каким способом осуществляется изоляция подпроектов, команд друг от друга?
Добрый день.
Весь проект в целом это множество систем — и микросервисов, и монолитов со своими базами данных, интеграциями и прочее. В общем, это целая экосистема.
И наша команда делает отдельный набор сервисов, по определенному бизнес-направлению.
То есть проблемы вписывания кода команды в некую общую кодовую базу нет (мне показалось, что вопрос он именно в этом) — разные команды делают отдельные сервисы.
Доступ к проектам друг друга у команд есть, шаринг как кода, так и знаний поощряется.
Весь проект в целом это множество систем — и микросервисов, и монолитов со своими базами данных, интеграциями и прочее. В общем, это целая экосистема.
И наша команда делает отдельный набор сервисов, по определенному бизнес-направлению.
То есть проблемы вписывания кода команды в некую общую кодовую базу нет (мне показалось, что вопрос он именно в этом) — разные команды делают отдельные сервисы.
Доступ к проектам друг друга у команд есть, шаринг как кода, так и знаний поощряется.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как дискомфорт помогает нам совершенствовать процесс разработки