A
а то нахуячат своих диаграмм а потом уходят в закат =)
Size: a a a
2021 June 16
AV
Проблема как раз таки в том, о чем недавно и обсуждалась проблема менеджеров. Люди, которые не работают с кодом будут винить именно программистов, когда что-то нельзя реализовать по их "супер мега крутой идее"
OR
обратную связь можно собирать не только посредством написания кода.
При этом, в больших системах невозможно кодить так, что бы прочувствовать все нюансы и все проблемы вызванные неправильным проектированием.
При этом, в больших системах невозможно кодить так, что бы прочувствовать все нюансы и все проблемы вызванные неправильным проектированием.
OR
Тут наоборот есть ловушка в том, что человек который спроектировал систему, будет понимать, что и как.
И ему как раз будет очень удобно.
А вот тем, кто действительно разрабатывает ее, наоборот.
И ему как раз будет очень удобно.
А вот тем, кто действительно разрабатывает ее, наоборот.
PD
Можно, только часто хуже это работает . И да, не всегда возможно. Но суть то не меняется.
PD
А должна телега ехать, и чтоб те кто её катит - не страдали и не бежали с этой телеги :)
OR
Для этого нужно собирать обратную связь от них, как от пользователей. А не пытаться что-то понять, через призму своей субъективности.
A
угу проект уже пилиться - а давайте обратную связь и мы конечно же поменяем ключевые компоненты архитектуры если они хреновые =)
A
при этом в прототипе это бы стало понятно
PD
И это тоже хорошо, но опять же, формулируете очень заковыристо, будто призм субъективности в собирании фидбека будет точно меньше :)
OR
Меньше мне кажеться, потому что фидбек собирается от непосредственных пользователей
PD
Призма субъективности у архитектора не пропала, и добавилась от пользователей :)
OR
Опять же, не вижу как бы кодинг архитектора помог бы в таком случае.
PD
Но вообще, чего мы муслим. Основная то мысль была в том, что непосредственное участие в «рутине» разработки какое-то время - один из самых эффективных способов сбора того самого фидбека.
A
Архитектор выше этого ! Ему нужно диаграммы рисовать, некогда в код погружаться с крестьянами =)
OR
спорный тезис.
но думаю не стоит на второй круг заходить.
но думаю не стоит на второй круг заходить.
OR
Просто вот допустим. Вы архитектор.
У вас сложная система с бекендом на микросервисах, фронтом на каком-то ангуляре, приложением на котлине.
Архитектор должен кодить во всех частях системы или как ему познать боль своих решений?
У вас сложная система с бекендом на микросервисах, фронтом на каком-то ангуляре, приложением на котлине.
Архитектор должен кодить во всех частях системы или как ему познать боль своих решений?
ch
А почему бы с самого начала тогда не зайти с другого конца, и позволить высказаться разработчикам об архитектуре с точки зрения людей которые будут ее реализовывать?
OR
я думаю делать это стоит, но при этом учитывать, что они могут не видеть всей картины.
AV
А как понять, что есть точка зрения, которая "верная"?