ST
тема верно сформулирована
Size: a a a
2020 June 16
ST
теги: governance, policy, opa, rego
OT
Всем привет! Разработчики Додо Пиццы решили описать историю развития архитектуры своей системы Dodo IS. Делюсь ссылкой, может быть кому-то будет интересно почитать, покритиковать их ИТ-решения =)
https://habr.com/ru/company/dodopizzadev/blog/506136/
https://habr.com/ru/company/dodopizzadev/blog/506136/
AD
уже читали, ощущение что делали на супер скорую руку не покидает всё время. а технологии и практики построение системы, делали люди которые видимо давно в разработке.
PD
О да, там почти все сделано, гм, кривовато - причем просто из--за того, что не подумали при проектировании.
GK
О да, там почти все сделано, гм, кривовато - причем просто из--за того, что не подумали при проектировании.
Не подумали при проектировании, часто значит - не проектировали, не считали нужным уделять время проектированию
PD
Ну, там же скрам...
GK
Ну, там же скрам...
😊
RT
Ну, там же скрам...
Ох наелся я таких проектов….
Проект становится проклятием его разработчика, ибо постоянно требует ремонта и переделок.
Проект становится проклятием его разработчика, ибо постоянно требует ремонта и переделок.
OT
А бывают такие проекты, которые не нужно ремонтировать и чинить?
G
А бывают такие проекты, которые не нужно ремонтировать и чинить?
https://github.com/kelseyhightower/nocode Один из таких проектов
RV
Платформа успешно поддерживает успешный бизнес, ИМХО, в конечном счете это главная метрика качества)
PD
А бывают такие проекты, которые не нужно ремонтировать и чинить?
Бывают. Но ремонтировать и чинить можно уменьшая сложность, а можно - увеличивая
S
А бывают такие проекты, которые не нужно ремонтировать и чинить?
только на бумаге
RT
Платформа успешно поддерживает успешный бизнес, ИМХО, в конечном счете это главная метрика качества)
Это утверждение очень сложно измерить.
Мне довелось видеть скрам-проекты, которые тянут за собой огромный хвост затрат на сопровожение, функциональность одноразовая, требует переделки при любом изменении. Такой проект становится проклятием его разработчиков: вместо того чтобы делать новые сервисы, время уходит на постоянное поддержание работоспососбности старого.
Мне довелось видеть скрам-проекты, которые тянут за собой огромный хвост затрат на сопровожение, функциональность одноразовая, требует переделки при любом изменении. Такой проект становится проклятием его разработчиков: вместо того чтобы делать новые сервисы, время уходит на постоянное поддержание работоспососбности старого.
RT
Но статья годная, спасибо.
Наглядный кейс переработки системы.
Многие проходят тот же путь.
Наглядный кейс переработки системы.
Многие проходят тот же путь.
I
На эту тему как раз назревает митап 25-го числа: https://www.meetup.com/Virtual-Domain-Driven-Design-meetup/events/271202418/
OT
Но статья годная, спасибо.
Наглядный кейс переработки системы.
Многие проходят тот же путь.
Наглядный кейс переработки системы.
Многие проходят тот же путь.
Спасибо! Передам автору ваши слова.
GK
На эту тему как раз назревает митап 25-го числа: https://www.meetup.com/Virtual-Domain-Driven-Design-meetup/events/271202418/
Не совсем на эту, я имел ввиду desing vs funny coding
GK
@emacsway но вообще, тема интересная