Comments 8
Abstraction focuses upon the essential characteristics of some object, relative to the perspective of the viewer.
©Гради Буч
По мере того, как команда проекта будет получать опыт, ее представления о рынке, его потребностях, а потому - о будущих продуктах, будут меняться. Это будет означать, что и целевая архитектура будет меняться.
Эта идея и приводит вас в тот дивный мир legacy, о котором вы так нелестно отзывались в начале. Вы уже со старта стоите легаси. Архитектура - это основа. Она необходима, для экономии усилий и времени. Замена основы - дорого и долго а значит и лишает всякого смысла изначальное планирование. Хотите заняться прототипированием - пишите говнокод, обгоняйте конкурентов, а уже потом стройте архитектуру и продукт.
Могу предложить простое правило проектирования: "не занимайтесь архитектурой, если вы не архитектор".
Могу предложить простое правило проектирования: "не занимайтесь архитектурой, если вы не архитектор".
Если бы все придерживались этому правилу как бы появились "архитекторы" ?
Как и все остальные - наймом или назначением. Подход, что сначала у нас появится код, а потом мы наймем разработчика - не очень полезный. Повозможнности старайтесь избегать этого.
Возможно вы ответили не на ту ветку ?
речь о том что если бы все придерживались правила "не занимайтесь архитектурой, если вы не архитектор" то как бы появились первые архитектор ? они бы либо не придерживались этого "правила", либо о нем не знали, либо никогда бы не стали архитекторами.
Минутка офтопа, архитектуру возводят в ранг религии типо это что такое непоколебимое, но как можно принимать решения на старте проекта которые повлияют на решения через год ? требования меняются постоянно, поэтому смысл тратить много времени на "архитектуру" на начальных этапах когда еще недостаточно компетенции в данном вопросе, вещь мягко говоря сомнительная, это уже из опыта, это был оффтоп.
ps минус поставил вам не я.
Нет, веткой я не ошибся и минус мне видимо за не ясное изложение ответа заслуженно.
Архитектор появляется, когда человека назначают или нанимают. Это важно - сначала необходима должность и человек, а потом продукт его деятельности - архитектура. Не было когда-то архитекторов. Были знатоки и специалисты. Кто-то пришел к выводу, что нужно упорядочить процесс проектирования и решили назначить Васю. Вася стал архитектором. То что было до этого - опыт, интуиция и тд. Это не архитектура, а рулетка. Появился Вася, который отвечает за проектирование и занимается им - теперь есть тот, кто сфокусирован на работе, продуктом, которой будет архитектура.
Моя аналогия с разработчиком подчёркивает важность того, что сначала есть человек, а потом результат. Не появляется код, а потом думают может нам разработчика нанять... Кстати, вот с девопсами часто работает как раз наоборот - сначала проблема, а потом девопс как решение.
Архитектура как раз потеряла всякий ранг и каждый думает, что любая диаграмма и документ - уже архитектура. Не понимание сложности и смыла процесса приводит к тому, что каждый вставляет свои 5 копеек, а ответственности никто не несет. Полное обесценивание - это как раз сказать, что мы через месяцок всю архитектуру переделаем...
Архитектура проекта - это долгий процесс и мой опыт о том как его уложить в динамику и agile тут.
Это важно - сначала необходима должность и человек, а потом продукт его деятельности - архитектура.
наивность во мне говорит, что в начале есть требования(или процесс) потом архитектура, с изменением требованиям появляется необходимость в изменение архитектуры (техдолг), что же касается должности и человека это совсем необязательно.
прочитав ваш комментарий можно сделать вывод что архитектура это результат деятельности проектирования "Васи". Если всю работу по архитектуре передать на одного человека (или группу людей) то у них не останется времени на реализацию, а продукт это не то что мы хотели реализовать, а то что у нас получилось в итоге, отсюда имея самую лучшую архитектуру можно получить ужасную реализацию и ужасный продукт, да я знаю что продукт не только его реализация, но и его продвижение и тд, будем их считать одинаковой константой.
Архитектура как раз потеряла всякий ранг и каждый думает, что любая диаграмма и документ - уже архитектура
Никто не может дать четкое определение того что такое архитектура и почти всегда получается довольно субъективное определение, либо она что то дублирует.
Не понимание сложности и смыла процесса приводит к тому, что каждый вставляет свои 5 копеек, а ответственности никто не несет
Этому даже дали название DDD, когда нам было сложно понимать процессы либо они слишком сложны, поэтому будем применять универсальные решения и код тут далеко не на первом месте.
а ответственности никто не несет.
А кто должен нести ответственность ? а за что ответственность ? за "архитектуру" или за продукт или за его реализацию ? кто может проверить "архитектуру" кроме "Васи"?
Полное обесценивание - это как раз сказать, что мы через месяцок всю архитектуру переделаем...
Что в этом плохого ?
если например реализовали процесс покупки товара через корзину, а потом бизнес сказал ой, нам надо не продавать товар, а осуществлять подписку на ... и следом за изменением процесса изменили "архитектуру" и решение (корзины) и текущая система позволила это сделать без side effect для системы в целом, это ли не пример хорошей архитектуры ?
Очень часто даже бизнес не до конца понимает что он хочет в итоге и иногда выстреливают совсем внезапные вещи о которых даже не думали или бизнес хочет проверить гипотезу и надо asap либо выстрелит и сделаем лучше или похороним.
Архитектура проекта - это долгий процесс и мой опыт о том как его уложить в динамику и agile тут.
Не читал, добавил в закладки прочитаю позже.
ой получилось очень много букв, весь мой посыл откуда взятся Васи если бы он придерживался правила "не занимайтесь архитектурой, если вы не архитектор"
Я считаю что архитектурой может заниматься в том числе и разработчик если он в силах предложить решение (это позволит ему рости как специалисту), другое дело что его решение нужно показывать более опытным коллегам или другим разработчикам, также как и "архитектор" должен создавать решения("архитектуру") учитывая возможности команды, из этих решений уже и надо выбирать ответственным с учетом возможности его дальнейшей поддержки.
Архитектуру можно сравнительно точно определить по процессу выше, чётко осознав и сформулировав:
что ДОЛЖНО делать новое решение (каков конкретный круг задач - хранить и раздавать данные контрагентов, предположительно, юрлиц например, как в статье)
что НЕ ДОЛЖНО делать новое решение (что из смежных областей и схожих задач точно не понадобится - например, относительно примера из статьи, должны ли мы будем хранить данные физлиц, можем ли мы в будущем заниматься физлицами. Если не можем - то и заранее планировать циркуляцию специфических для физлиц данных не нужно)
В т. ч. именно за этим нужны пункты 2-4.
Если при конкретизации уже очерченых в скоупах ДОЛЖНО/НЕ ДОЛЖНО задач за каким-то лядом понадобилось значительно менять архитектуру - видимо, надо либо перезапускать процесс, либо задуматься, а подходит ли под эти круги задач выбранное решение сочетание технологического стэка и методологии.
Либо присмотреться к участникам процесса повнимательнее...
Могу предложить простое правило проектирования: "не занимайтесь архитектурой, если вы не архитектор".
*троекратное ХА в адрес любителей взвалить эту задачу на кого попало. В т. ч. из-за чего порой и приходится прибегать к таким комплексным процессам с изобилием совершенно произвольных привлечённых людей*
Правильная архитектура данных с первых спринтов