Еще бы экспериментальные данные под это подложить статья была бы сильно полезнее. Тут еще можно играться с точкой пересечения. Как пример сдвинем ее правее и востребованность доработок\продукта может быть равна 0. Можно наложить рассуждения на две модели - для примера рассмотрел два варианта запуск стартапа и разработку коробочного решения с понятным функционалом и планом на 3-5 лет
В статье очень спорных утверждения относительно автоматизации:
Валидация программ и проблема останова. При этом упускается момент, что при этом есть подмножество программ которые вполне успешно валидируются. Но что более важно человек который проводит тестирование руками точно так же не может доказать корректность работы + к этому подвержен влиянию внутренних факторов (усталость и т.д.)
Тезис про наказание кажется не совсем к месту. Автоматизация здесь абсолютно перпендекулярна
При этом общий тезис валидный граница автоматизации определяется с учетом бизнеса, рисков и сложности автоматизации
Претензия не к объяснению а к заголовку, он максимально кликбейтный — "С помощью перехода на микросервис мы ускорили бизнес-процесс в 60 раз"
Вы могли вынести логику расчета на любую архитектуре и получить такой же результат
Не понятно в чем тут помогли микросервисы. Микросервисы в частности решают проблему масштабируемости команд и совместной разработки
Если в вашем примере вынести функциональность в сервис — принципиально ничего не измениться
Поэтому в Java REPL это такой "огрызок" (без него жили вполне успешно) — снипеты позапускать, однострочники проверить. Разработку через REPL никто не ведет
В Lisp наоборот вся разработка через REPL, загрузил образ, стейт и погнали
Действительно если у нас нетривиальное обновление\изменение\инвалидация кэша в зависимости от окружения\запросов и т.д. то заново загрузить его под новую структуру\класс в Lisp мы не сможем. Тут у нас с вами паритет
Но если посмотреть на подходы к разработке в Java и CL они в корне отличаются
На Java бОльшая часть разработки опирается на помощь Idea, автокомплит, типы и т.д. Т.е я не запускаю приложение из раза в раз, потому что это достаточно медленно
В Lisp же наоборот я начинаю с "запуска приложения" и постоянно в нем что-то дорабатываю, добавляю поля в структуры, меняю порядок вызова функций и все это на рабочем приложении
И потерять весь стейт и это без учета всяких Spring boot'ов и других фреймворков которые накладывают свои ограничения на этот процесс
В мире Java ближе всего к CL REPL подошел Clojure но и тот недотягивает
В этом вся соль в Lisp можно менять что угодно до\после\вместо функции
В жабке это прибито гвоздями, ну и будем честны REPL в массы в Java не пошел
БОльшинство команд, с которыми мне приходилось общаться, предпочитают классику — пошаговую отладку в Idea
Такого REPL как в лиспе я нигде не видел, даже Clojure в этом плане на шаг позади. Больше всего кайфовал на отладке багов где без потери стейта системы можно поменять функцию (добавить отладку и т.п.) и заново прогнать вызов и тут же поправить
Иметь возможность расширять команду, с этим у лиспа большие проблемы
Современная документация с примерами решения задач (начинал с PCL и обалдел от возможности сделать одно и то же 10 способами)
Набор хорошо поддерживаемых библиотек (в Lisp с этим есть определенные проблемы, как пример веб сервер с хорошей производительностью и набором фич — ssl\websockets\oauth и т.д. желательно без дополнительных приседаний)
и т.д.
Насколько шаблоны дают выигрыш в ТТМ?
Возможно на первом этапе внедрения MSOA это частый кейс. По мере роста числа MS задачи будут уходить в сторону перераспределение зависимостей и доработки отдельных MS
Что еще хотелось отметить — "… возможность быстро и централизованно обновлять набор библиотек..." при таком подходе нарушатся независимость MS и оч. часто начинает возникать Dependecy hell когда зависимости в шаблоне конфликтуют с зависимостями в MS
Часть про Web освещена как то слабо, ждешь чего-то большего личного опыта, кейсов
В каких случаях и по каким показателям, кроме performance, дает ощутимый прирост в разработке, стоимость поддержки и т.д.
По моим ощущениям haskell развивается и поддерживается гораздо лучше CL. Не так давно добавили поддержку линейных типов
Еще бы экспериментальные данные под это подложить статья была бы сильно полезнее. Тут еще можно играться с точкой пересечения. Как пример сдвинем ее правее и востребованность доработок\продукта может быть равна 0. Можно наложить рассуждения на две модели - для примера рассмотрел два варианта запуск стартапа и разработку коробочного решения с понятным функционалом и планом на 3-5 лет
В статье очень спорных утверждения относительно автоматизации:
Валидация программ и проблема останова. При этом упускается момент, что при этом есть подмножество программ которые вполне успешно валидируются. Но что более важно человек который проводит тестирование руками точно так же не может доказать корректность работы + к этому подвержен влиянию внутренних факторов (усталость и т.д.)
Тезис про наказание кажется не совсем к месту. Автоматизация здесь абсолютно перпендекулярна
При этом общий тезис валидный граница автоматизации определяется с учетом бизнеса, рисков и сложности автоматизации
Претензия не к объяснению а к заголовку, он максимально кликбейтный — "С помощью перехода на микросервис мы ускорили бизнес-процесс в 60 раз"
Вы могли вынести логику расчета на любую архитектуре и получить такой же результат
Не понятно в чем тут помогли микросервисы. Микросервисы в частности решают проблему масштабируемости команд и совместной разработки
Если в вашем примере вынести функциональность в сервис — принципиально ничего не измениться
К сожалению в плане библиотек и их качества го пока еще в догоняющих
Вам выше quarkus предлагали, там и graalvm и memory footprint и время старта отличные)
Только не под GraalVM
Поэтому в Java REPL это такой "огрызок" (без него жили вполне успешно) — снипеты позапускать, однострочники проверить. Разработку через REPL никто не ведет
В Lisp наоборот вся разработка через REPL, загрузил образ, стейт и погнали
А как вы расхождение типов фиксите? С лиспом понятно он динамический, а вот с java и scala не понятно
Действительно если у нас нетривиальное обновление\изменение\инвалидация кэша в зависимости от окружения\запросов и т.д. то заново загрузить его под новую структуру\класс в Lisp мы не сможем. Тут у нас с вами паритет
Но если посмотреть на подходы к разработке в Java и CL они в корне отличаются
На Java бОльшая часть разработки опирается на помощь Idea, автокомплит, типы и т.д. Т.е я не запускаю приложение из раза в раз, потому что это достаточно медленно
В Lisp же наоборот я начинаю с "запуска приложения" и постоянно в нем что-то дорабатываю, добавляю поля в структуры, меняю порядок вызова функций и все это на рабочем приложении
И потерять весь стейт и это без учета всяких Spring boot'ов и других фреймворков которые накладывают свои ограничения на этот процесс
В мире Java ближе всего к CL REPL подошел Clojure но и тот недотягивает
В этом вся соль в Lisp можно менять что угодно до\после\вместо функции
В жабке это прибито гвоздями, ну и будем честны REPL в массы в Java не пошел
БОльшинство команд, с которыми мне приходилось общаться, предпочитают классику — пошаговую отладку в Idea
Скорее Clojure
Такого REPL как в лиспе я нигде не видел, даже Clojure в этом плане на шаг позади. Больше всего кайфовал на отладке багов где без потери стейта системы можно поменять функцию (добавить отладку и т.п.) и заново прогнать вызов и тут же поправить
Нужно не много но в хорошем качестве, например
и т.д.
Тогда не совсем что имелось ввиду под фразой про централизованное обновление библиотек в микросервисах
Насколько шаблоны дают выигрыш в ТТМ?
Возможно на первом этапе внедрения MSOA это частый кейс. По мере роста числа MS задачи будут уходить в сторону перераспределение зависимостей и доработки отдельных MS
Что еще хотелось отметить — "… возможность быстро и централизованно обновлять набор библиотек..." при таком подходе нарушатся независимость MS и оч. часто начинает возникать Dependecy hell когда зависимости в шаблоне конфликтуют с зависимостями в MS
Java в работе с памятью не так плоха, есть GraalVm и те же микрофреймворки типа quarkus и иже с ними
Потребление памяти в них приятно удивляет
Часть про Web освещена как то слабо, ждешь чего-то большего личного опыта, кейсов
В каких случаях и по каким показателям, кроме performance, дает ощутимый прирост в разработке, стоимость поддержки и т.д.