Насчет "Пролетария" не помню, а вот на ЗИЛе была оч крутая автоматизация склада от стеллажа до места сборки. Но насколько помню не оч экономически эффективно оказалось, человечий труд дешевле был )
Артем, безусловно у каждого свой опыт и контекст. Я работал в основном в "кровавом энтерпрайзе", и помимо критериев нагрузки и влияния на результат, есть еще важный критерий "кроссдоменности" задачи, с которой даже вполне вменяемые команды справляются сильно дольше в отсутствии архитектора. И чем более "микросервисный" и сепарированный ландшафт, тем значимей роль архитектора и для конкретных задач, и в целом для "всея-ИТ" метрик типа TCO, T2M и т.д.
"Краевые эффекты" конечно бывают, но в данном случае мы их не рассматриваем, считая априори что доработки были заранее оценены по продуктовым метрикам типа CIR и принято решение что делать "выгодно". На практике, если не брать регуляторку, я очень редко встречал команды которые из года в год делают убыточные проекты
мы кмк смешиваем PoC и MVP. Часто у "бизнеса" есть ожидания что после успешного РоС его можно развивать дальше. По моему опыту это приводит к огромным проблемам с развитием этого функционала
Артем, уточните плз какую мысль вы имели в виду? По моему опыту именно архитектор часто фасилитирует межкомандное взаимодействие, позволяя им договориться до решения в рамках "многокомандной" задачи. И здесь как раз в крупных компаниях это довольно острая проблематика. Если мы говорим про фокус внутрь команды - тут опять же про какого архитектора мы говорим? Солюшн скорее может посоветовать какие-то решения в части ньюансов реализации, но команда однозначно больше в контексте и примет в среднем лучшее решение.
Именно поэтому в России практически нет международно успешных проектов.
Вы уверены что их нет? И прям точно знаете что причина только в этом? Может быть есть какие то исследования, подверждающие дефективность российских разработчиков?
Ему нужен продукт, который понравится. Даже, если код не оптимизирован.
Вот только проблема в том что через пол-года когда стоимость изменений этого кода достигнет космических значений, ровно тот же самый заказчик будет спрашивать "а что так долго"? "Почему заранее не предусмотрели?" и в конце скажет что не готов тратить на рефакторинг потому что ему надо бизнес показатели улучшать и "придумай что-нибудь".
В рамках второй основной задачи достаточно прозрачно и очевидно, что подмена учителя-воспитателя репетитором, а образования – образовательными услугами из школьника гражданина воспитать не способны.
Не очевидно, как по мне это классическая манипуляция. Из учителей воспитатели нисколько не лучше чем из родителей на моей выборке.
Кмк не прозвучало самое интересное - вот вы перенесли сущность в МС из монолита. Но чтобы все "стыкующиеся" бизнес-процессы, которые еще не вынесены, не сломались - мы начинаем данные зеркалить в монолит. Также поступает и команда-сосед. И кмк есть серьезный риск что через 2-3 года ситуация может сложиться такая - есть куча МС, но все еще есть монолит со всеми ключевыми сущностями. Cost of change не изменился или вырос, ошибки за счет неконсистентности данных выросли, ТСО тоже вырос хотя бы по железу. Вопрос - как вы работаете с такого рода рисками "сцепленности" процессов в монолите?
Если ответ на запрос1 содержит данные о клиенте и телефоне, ответ за запрос2 - данные о клиенте и email, то кэш не сможет сам ответить на запрос клиент+телефон+мыло? Для него это просто ответ1 и ответ2 и какие данные там ему не очень интересно?
Спасибо, понял) Как идея для рефлексии - а может начать с нуля рядом где-нибудь? "контракт" же все равно тот же останется, А/Б тест легко покажет стоит дальше вкладывать или нет )
Возможно упустил, но правильно ли я понял что ваша схема не предполагает ответ из кеша на запрос3 если он является сопоставлением данных кеша по запросу1 и запросу2. Т.е. кэш не знает бизнес-смысл данных?
Зошто Саратов то сразу? )) За малую родину обидно )
Насчет "Пролетария" не помню, а вот на ЗИЛе была оч крутая автоматизация склада от стеллажа до места сборки. Но насколько помню не оч экономически эффективно оказалось, человечий труд дешевле был )
Спасибо за ОС, я вообще хотел +/- про всех, но видимо не совсем удачно) можете плз тыкнуть где именно смешение есть на ваш взгляд?
Артем, безусловно у каждого свой опыт и контекст. Я работал в основном в "кровавом энтерпрайзе", и помимо критериев нагрузки и влияния на результат, есть еще важный критерий "кроссдоменности" задачи, с которой даже вполне вменяемые команды справляются сильно дольше в отсутствии архитектора. И чем более "микросервисный" и сепарированный ландшафт, тем значимей роль архитектора и для конкретных задач, и в целом для "всея-ИТ" метрик типа TCO, T2M и т.д.
Павел, можете плз уточнить чуть детальней - стоимость чего именно не раскрыта?
Еще Ницше говорил что фактов нет, есть только наша интерпретация их.
"Краевые эффекты" конечно бывают, но в данном случае мы их не рассматриваем, считая априори что доработки были заранее оценены по продуктовым метрикам типа CIR и принято решение что делать "выгодно". На практике, если не брать регуляторку, я очень редко встречал команды которые из года в год делают убыточные проекты
мы кмк смешиваем PoC и MVP. Часто у "бизнеса" есть ожидания что после успешного РоС его можно развивать дальше. По моему опыту это приводит к огромным проблемам с развитием этого функционала
Артем, уточните плз какую мысль вы имели в виду? По моему опыту именно архитектор часто фасилитирует межкомандное взаимодействие, позволяя им договориться до решения в рамках "многокомандной" задачи. И здесь как раз в крупных компаниях это довольно острая проблематика. Если мы говорим про фокус внутрь команды - тут опять же про какого архитектора мы говорим? Солюшн скорее может посоветовать какие-то решения в части ньюансов реализации, но команда однозначно больше в контексте и примет в среднем лучшее решение.
Саш, не стоит воспринимать так буквально) Это сборник из моего опыта и опыта коллег. В т.ч. и опыта общения с некоторыми консалтерами ))
Нет, с тем же успехом так сказать нельзя, это манипуляция чистой воды. Абсолютно разные предметные области.
Вы уверены что их нет? И прям точно знаете что причина только в этом? Может быть есть какие то исследования, подверждающие дефективность российских разработчиков?
Вот только проблема в том что через пол-года когда стоимость изменений этого кода достигнет космических значений, ровно тот же самый заказчик будет спрашивать "а что так долго"? "Почему заранее не предусмотрели?" и в конце скажет что не готов тратить на рефакторинг потому что ему надо бизнес показатели улучшать и "придумай что-нибудь".
Я рад что помог вам добавить определенности в этом вопросе. Вполне может так быть, что для вашей ситуации и контекста он и правда не нужен
Бывает и такое)
Не очевидно, как по мне это классическая манипуляция. Из учителей воспитатели нисколько не лучше чем из родителей на моей выборке.
спасибо, а с заказом таких проблем случайно не было у вас? )
Кмк не прозвучало самое интересное - вот вы перенесли сущность в МС из монолита. Но чтобы все "стыкующиеся" бизнес-процессы, которые еще не вынесены, не сломались - мы начинаем данные зеркалить в монолит. Также поступает и команда-сосед. И кмк есть серьезный риск что через 2-3 года ситуация может сложиться такая - есть куча МС, но все еще есть монолит со всеми ключевыми сущностями. Cost of change не изменился или вырос, ошибки за счет неконсистентности данных выросли, ТСО тоже вырос хотя бы по железу. Вопрос - как вы работаете с такого рода рисками "сцепленности" процессов в монолите?
Если ответ на запрос1 содержит данные о клиенте и телефоне, ответ за запрос2 - данные о клиенте и email, то кэш не сможет сам ответить на запрос клиент+телефон+мыло? Для него это просто ответ1 и ответ2 и какие данные там ему не очень интересно?
Спасибо, понял) Как идея для рефлексии - а может начать с нуля рядом где-нибудь? "контракт" же все равно тот же останется, А/Б тест легко покажет стоит дальше вкладывать или нет )
Возможно упустил, но правильно ли я понял что ваша схема не предполагает ответ из кеша на запрос3 если он является сопоставлением данных кеша по запросу1 и запросу2. Т.е. кэш не знает бизнес-смысл данных?