Автор, а что для Вас значит «программирование развивается». Новые языки для Вас не развитие, развитие существующих языков тоже. Эдак можно вообще всё к машине Тьюринга свести и сказать, что да, вот там был прорыв, а с тех пор никакого особо развития.
> Теперь мы можем оценить — плохая ли у нас архитектура или хорошая
Думаю нет, поскольку предложенная оценка не даёт понимания, сколько лишних абстракций у вас создано, а только лишь — сколько абстракций не хватает для запрошенных изменений.
При работе с кодом несколько уровней абстракции, созданных «на будущее», чтобы потом попасть в О(1), совсем не добавляют прозрачности и понимания. Особенно «не скучно» становится, когда вы не угадали со структурой абстракций (редко разработчик знает предметную область лучше заказчика).
1. Вполне может быть, что быстрее получится протестировать и обновить несколько важных микрофронтендов, и затем подтягивать хвосты, чем переезжать на поправленную версию всем монолитом (если же у вас компактный монолит, то зачем было ехать в микрофронтенды?).
2. Изменение сквозной функциональности — если это значимый кейс, то вероятно микрофронтенды неправильно организованы и оказались сильно связаны.
3. По поводу совместимости со свежей/старой версией браузера — обычно проблема не возникает сразу во всех микрофронтендах. Тут как раз двигать всех в светлое будущее может быть вредно.
PS: Понятно, что если микрофронтенды использованы без нужды и просто потому что это модный тренд, то всё будет плохо. Ну так и микросервисы можно использовать не по назначению.
Да, я именно про это, что такой сервис RPA теперь потребует вокруг себя всю обычную для любого сервиса инфраструктуру, которой у нового проекта взяться неоткуда и придётся её создавать, или страдать от её отсутствия. Выкатили правки без автотестов — прод прилёг => все в мыле бегают и решают инцидент (а логов и мониторинга поди тоже нет).
Американский стартап ScaleFactor шесть лет уверял клиентов из малого бизнеса, что разработанная им программа может полностью взять на себя их финансы. Именитые инвесторы успели вложить в сервис $100 млн, пока не обнаружили, что все расчеты на самом деле ведет не искусственный интеллект, а делают вручную обычные бухгалтеры
Зашел, попробовал воспользоваться, случился такой диалог:
Привет! Что тебя беспокоит?
> температура 39
Попробуйте описать свой недуг другими словами…
> высокая температура
Уместно ли будет сказать, что вас беспокоит Цианоз? (Да/Нет)
> Нет
Попробуйте описать свой недуг другими словами…
> повышенная температура
Целесообразно ли утверждение, что вас беспокоит Повышенная энергичность? (Да/Нет)
> Нет
Попробуйте описать свой недуг другими словами…
> у меня температура 39 градусов
Ура! С днём рождения! Счастья, здоровья, успехов во всём!
Возможно автор в словосочетании «преждевременная оптимизация» не понял первое слово.
Проблема в том, что часто от создания действующего макета до итогового продукта всё значительно меняется несколько раз (например, оказывается, что в реальной жизни тут не одна сущность, а пара, в отношении 1-к-многим). И каждый такой раз есть вероятность, что преждевременная оптимизация:
1. Будет усложнять корректировку под изменившуюся задачу.
2. Будет выброшена на помойку.
Один клиент является агентом рынка, да, но не рынком. После нескольких месяцев разработки переход между 1 и 2 клиентом кардинальный и ваш кейс еще одно тому доказательство.
Я не про ценность, а про то, что называть одного клиента «рынком» — на мой взгляд странно. Судя по остальному тексту на «рынок» не то что не выводили продукт, но и даже и не планировали.
Не совсем понял, что значит «вывод конкурентного решения на рынок «умной поддержки»» если у «стартапа» был один клиент и это суть была разработка под его специфичные нужды?
30 микросервисов, каждый в своём репо с отдельным репо для синхронизаций для интеграции порядка 10 систем с первого взгляда выглядит, как оверинжиниринг.
Интересно, почему не вышло сделать в монорепо и условно 10 микросервисов адаптеров по количеству интегрируемых систем + ну максимум 3-5 сервисов общих? Если не секрет, по какому принципу делили микросервисы?
Не кажутся нужными какие-то правила в линтере? Ну так обсудите в рамках компании/проекта/команды и поменяйте набор правил, в чем сложность? Вроде нынче любой линтер позволяет контролировать только то, что хочется. При этом вполне может оказаться, что в ходе обсуждения Вы осознаете, зачем эти правила были введены.
Это кстати частая проблема принятых когда-то решений, что решение осталось, а история, как, кем и зачем оно было принято — нет. У той же Atlassian есть прекрасная традиция в культуре компании — все принятые решения фиксируются не только в части «что решили», но и «кто, зачем, какие факторы были учтены» и т.д.
Микросервисы связываются между собой через протоколы, а это порождает, например:
— сложность в управлении сетевым трафиком и задержки;
— сбои запросов и другие ошибки;
— необходимость сериализовать данные и шифровать соединения.
И тут же рисуете целевое состояние системы ровно с этими проблемами.
А можно тогда Ваше определение «новых качеств» ЯП узнать?
Думаю нет, поскольку предложенная оценка не даёт понимания, сколько лишних абстракций у вас создано, а только лишь — сколько абстракций не хватает для запрошенных изменений.
При работе с кодом несколько уровней абстракции, созданных «на будущее», чтобы потом попасть в О(1), совсем не добавляют прозрачности и понимания. Особенно «не скучно» становится, когда вы не угадали со структурой абстракций (редко разработчик знает предметную область лучше заказчика).
2. Изменение сквозной функциональности — если это значимый кейс, то вероятно микрофронтенды неправильно организованы и оказались сильно связаны.
3. По поводу совместимости со свежей/старой версией браузера — обычно проблема не возникает сразу во всех микрофронтендах. Тут как раз двигать всех в светлое будущее может быть вредно.
PS: Понятно, что если микрофронтенды использованы без нужды и просто потому что это модный тренд, то всё будет плохо. Ну так и микросервисы можно использовать не по назначению.
Американский стартап ScaleFactor шесть лет уверял клиентов из малого бизнеса, что разработанная им программа может полностью взять на себя их финансы. Именитые инвесторы успели вложить в сервис $100 млн, пока не обнаружили, что все расчеты на самом деле ведет не искусственный интеллект, а делают вручную обычные бухгалтеры
Привет! Что тебя беспокоит?
> температура 39
Попробуйте описать свой недуг другими словами…
> высокая температура
Уместно ли будет сказать, что вас беспокоит Цианоз? (Да/Нет)
> Нет
Попробуйте описать свой недуг другими словами…
> повышенная температура
Целесообразно ли утверждение, что вас беспокоит Повышенная энергичность? (Да/Нет)
> Нет
Попробуйте описать свой недуг другими словами…
> у меня температура 39 градусов
Ура! С днём рождения! Счастья, здоровья, успехов во всём!
Это правда полноценный MVP?
Проблема в том, что часто от создания действующего макета до итогового продукта всё значительно меняется несколько раз (например, оказывается, что в реальной жизни тут не одна сущность, а пара, в отношении 1-к-многим). И каждый такой раз есть вероятность, что преждевременная оптимизация:
1. Будет усложнять корректировку под изменившуюся задачу.
2. Будет выброшена на помойку.
Интересно, почему не вышло сделать в монорепо и условно 10 микросервисов адаптеров по количеству интегрируемых систем + ну максимум 3-5 сервисов общих? Если не секрет, по какому принципу делили микросервисы?
Не кажутся нужными какие-то правила в линтере? Ну так обсудите в рамках компании/проекта/команды и поменяйте набор правил, в чем сложность? Вроде нынче любой линтер позволяет контролировать только то, что хочется. При этом вполне может оказаться, что в ходе обсуждения Вы осознаете, зачем эти правила были введены.
Это кстати частая проблема принятых когда-то решений, что решение осталось, а история, как, кем и зачем оно было принято — нет. У той же Atlassian есть прекрасная традиция в культуре компании — все принятые решения фиксируются не только в части «что решили», но и «кто, зачем, какие факторы были учтены» и т.д.
В обычном лего в машинке сотни деталек, а тут страшно представить отладку и поддержку программы из хотя-бы 50 блоков.
Вот уж где будет настоящий «спагетти-код».
Главное, чтобы это обучение не стало существенно сложнее, чем обучение программированию.
Микросервисы связываются между собой через протоколы, а это порождает, например:
— сложность в управлении сетевым трафиком и задержки;
— сбои запросов и другие ошибки;
— необходимость сериализовать данные и шифровать соединения.
И тут же рисуете целевое состояние системы ровно с этими проблемами.
Зачем так?
PS: Отдельно интересно, как удалось так далеко утащить security от apps.