Size: a a a

Архитектура ИТ-решений

2020 October 12

F

Fagor in Архитектура ИТ-решений
Igor A
Дискурс такой - "я обленился и разучился писать код - значит это признак истинно белой обезьяны".
Для бизнеса любое айти это почти всегда затраты. Неумение писать код - почти приговор в условиях когда за 5 лет все меняется. Невозможность собесить людей. Невозможность запилить прототип. Невозможность проголосовать ногами забугор.
источник

F

Fagor in Архитектура ИТ-решений
Цитата была выше, ваш выбор, писать код или заняться задачами другого слоя уровня. Тактика или стратегия, а не траншею копать. Или копать траншею.
источник

I

Ivan in Архитектура ИТ-решений
Igor A
Вот я тоже этого не понимаю. С чего архитектор проработавший 1г будет лучше знать системы чем сеньор сидящий там 5 лет?)
Знать реализованную систему конечно будет лучше тот, кто её создавал. А при плохом внутреннем качестве системы он станет еще и незаменимым. На эту тему была занимательная статья, перевод:
https://ain.ua/2017/10/17/we-fired-our-rick
Но знать систему - это немного не то, чтобы знать решение. Бывает такое, когда разработчик знает реализованную систему, но не знает решения, которое нужно реализовать. А именно это зачастую важнее.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
А, но в этой статье сплошной треш, ее подробно разбирали.
Такой провал менеджмента сложно придумать...
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Собственно статья очень показательна - проблемы начинаются раньше системной архитектуры и решать их лучше там.
источник

I

Ivan in Архитектура ИТ-решений
Phil Delgyado
А, но в этой статье сплошной треш, ее подробно разбирали.
Такой провал менеджмента сложно придумать...
Да, согласен, треша там много, и статья интересна для анализа управленческих ошибок. Но там в забавной форме показана проблема "незаменимого разработчика".
источник

I

Ivan in Архитектура ИТ-решений
Phil Delgyado
Да, я правильно понимаю, что про ускорение velocity говорилось для проектов, дошедших до стадии 'экспоненциальный рост стоимости изменений'? А не для любых нормально живущих проектов?
Это зависит от того, в каком месте кривой стоимости изменения кода находится проект, и какой у неё характер. В РФ я встречал достаточно неплохие проекты, но нераскрытый резерв по стоимости изменения кода у них все равно присутствовал. Не настолько большой, как в большинстве legacy проектов зарубежья, с которыми приходилось иметь дело, но все-равно был.
источник

S

Sergey in Архитектура ИТ-решений
Ivan
Знать реализованную систему конечно будет лучше тот, кто её создавал. А при плохом внутреннем качестве системы он станет еще и незаменимым. На эту тему была занимательная статья, перевод:
https://ain.ua/2017/10/17/we-fired-our-rick
Но знать систему - это немного не то, чтобы знать решение. Бывает такое, когда разработчик знает реализованную систему, но не знает решения, которое нужно реализовать. А именно это зачастую важнее.
нежное общество не выдержало токсичного чела?) даже не открывал статью, но вот чувствую именно так и было
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Дело в экспоненте или в чем?
По моему опыту стоимость внесения правок - скорее константа. Но для некоторого типа фич можно эту константу сильно понизить (архитектурными решениями или другими путями) - и вопрос как раз про то, для каких фич стоит инвестировать в уменьшение констант.
А вот такого, что бы стоимость похожих фич начинала расти - вот не помню даже в практике.
Но я мало видел западных проектов изнутри...
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
Тут ключевое слово похожих. Их все делают по проторенной дорожке. Интерес возникает, когда что-то новое приходит.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
А как оценить трудоемкость новых фич? Они же новые, их сложность не с чем сравнить.
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
Придумывается решение, раскладывается на задачи и дается оценка.
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
Не вижу проблемы дать оценку. Оценка может непорадовать заказчика - но это другой разговор
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Я не про это, я про утверждение, что в среднем проекте сложность добавления функциональности растет по экспоненте.
Для доказательства этого утверждения нужен именно поток похожих задач, что бы их сложность была очевидна близкой, а трудоемкость возрастала.
Для новых по типу фич нельзя сказать "сложность была очевидно такой же".
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
С этим утверждением тоже не соглашусь. Тут надо разделить фичи - новые и нет. Кейсы, когда бизнес приходит с простой по реализации (с его т.з. фичей), а разработка говорит - полгода надо - вполне себе живуч. И DDD для меня это в первую очередь снижение такого риска.
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
Phil Delgyado
Я не про это, я про утверждение, что в среднем проекте сложность добавления функциональности растет по экспоненте.
Для доказательства этого утверждения нужен именно поток похожих задач, что бы их сложность была очевидна близкой, а трудоемкость возрастала.
Для новых по типу фич нельзя сказать "сложность была очевидно такой же".
В смысле я с вами согласен.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Ну, DDD не всегда спасает про этот риск. По моему опыту бизнес не видит, например, разницы между поиску по префиксу, по подстроке и полнотекстовому. И никакой DDD не спасет, если вместо поиска по префиксу захотят полнотекстовый по имеющейся большой базе )
источник

IA

Igor A in Архитектура ИТ-решений
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Да, рынок именно так и устроен. Зарплата зависит от локации проживания. Звучит не рационально, вроде-бы какая разница, где живет человек. Но нет, имеет значение. Возможно это стереотип.

С другой стороны, компании, которые предлагают небольшую разницу существенно выигрывают в возможности выбора.

Условно, у хороших разработчиков в Ярославле есть возможность работать за почти Московскую зп. И при этом, в сухом остатке, с учётом стоимости жизни, доход в пересчёте на евро получается не меньше, чем в Мюнхене или Гамбурге, например. То есть, люди могут позволить себе не только хорошее жильё, дачи и прочие привычные вещи, но и путешествовать, и инвестировать.

При этом, в отличие от штатов, есть отпуска. Так что не всё однозначно.
источник
2020 October 13

IA

Igor A in Архитектура ИТ-решений
Формулировка московская зп смущает. Европейская может? Зачем им на москву работать?)
источник