Плюс статический анализатор кода.
Плюс кодогенератор.
Плюс много чего.
А так JVM — мир изначально строился по Unix-филсофии.
Поэтому компилятор, сборщик, система управления библиотеками/зависимостями и IDE это отдельные приложения.
Это дает возможность комбинировать и встраивать в другие приложения.
В частности в CI/CD.
А комбайны… Ну Eclipse по началу пытался идти в этом направлении.
Как оказалось это никому особо не нужно.
MS тоже двигает Visual Studio Code. Это вроде бы «просто редактор»
Везде где я работал по таймтрекингу часы писал «как надо».
Чтобы выходило 40 часов в неделю.
Особо не напрягало, но толку не было никакого.
Точнее толк был только, что по этому времени начисляли ЗП.
На продуктивность и решение задач никакого влияния не оказывало.
Да. Ладно. Это ещё норм.
У меня сейчас проект который работает на Java не выше 1.7.79, на 1.7.80 уже не работает, не говоря о версиях выше.
Я пришел, когда вся команда «Встала ушла».
Документация устарела лет на 5. Тесты не работают года 3.
И команда ушла, когда разрабатывали «новую фичу».
Пришлось доделывать новую фичу. И запускать на проде.
Благо основа была норм. Но после 5 поколений программистов, там много накопилось технического долга.
Ну у меня был опыт оплачиваемого тестового задания.
Т.к. собеседовался в другую страну, то были проблемы с переводом денег мне.
Не смотря на то что не прошел, менеджер «заморочился» и полторы недели пытался перевести мне деньги.
Деньги перевели, хотя я не настаивал.
Задание было не сложным. Как сказали, мой кодестайл не удовлетворил.
Из-за COVID-19 работаю удаленно.
Особых проблем нет.
Но в офисе мне легче работать.
Дома диван и холодильник постоянно отвлекают.
Жена и дети, кстати — нет.
Ребенку (3 года) спокойно объяснил, что папа работает. И он не мешает.
Жена играет с ребенком и дела по дому в другой комнате.
Но постоянно хочется «полежать, подумать». :-)
ИМХО тут надо различать логическую структуру БД и её физическую реализацию.
Как бы проблема шардинга, не должна касаться программистов, желательно, чтобы это была внутренняя кухня ДБА.
Здесь ТС рассматривает пайплайн для разработчиков.
Чтобы «отделить» программистов от ручных изменений в БД.
Т.к. все актуальные СУРБД к такому использованию приспособлены менее чем никак, то получается все очень неуклюже.
Вообще странно. Т.к. обычно в OLAP-кубы выгружают данные, таким образом, чтобы быстро получить срез, по той или иной аналитике.
При этом — да, загрузка данных может быть и долгой.
Но обычно это не критично.
Потом просто придется нанимать разработав заовердофига баксов.
Когда конкуренты будут брать задёшево обычных крудоклепателей.
При этом результат будет один и тот же. :-)
Я бы поспорил с ТС.
Т.к. да в рамках рассмотрения одного электрона, все слишком неопределенно.
Но если рассматривать массу электронов, в проводнике, то в зависимости от поданного напряжения, будет прослеживаться какая-то закономерность.
То же самое и с коррупцией.
Если в рамках рассмотрения одного человека, это как бы проблема.
То в рамках общества, может оказаться, что проблемы нет вовсе, а есть возможности. :-)
Я говорю над поколениями программистов работающими над проектом.
Если к самому SQL у меня претензий не только, нет, а наоборот, чтобы для работы с реляционными данными использовали только его.
А вот что касается императивных расширения для SQL (PlSQL, TSQL, PgPlSQL), то я лично, против их повального использования (чаще всего бездумного).
Скажем так, я не раз оказывался в ситуации, когда приходил на легаси проект, а предыдущие программисты уже ушли. Из документации только код без тестов, какое-то ТЗ которое было актуально лет 5 назад и все.
Разбираться в портянках хранимых процедур, это чуть лучше, чем разбираться в исходных кодах программы на Clipper.
Тут в хотя бы нельзя просто сделать сомомодефицируемую процедуру.
Хотя это можно сделать, но нужно немного извратиться.
Никто не спорит, что как ЯП различные СУПБД это классный инструмент.
Проблема начинается, когда проект разрастается до такого размера, что нужна работа команды из более чем трех человек.
И тут системы командной работы для СУРБД в зачаточном состоянии.
Системы коллективной работы для других ЯП (JAVA, C#, Python и пр) очень плохо интегрируются с СУРБД.
По мне, писать логику БП в СУРБД, это закладывать мину в проект, которая рванет, через 1.5 — 2 года, когда сменится как минимум пара поколений программистов.
Стоимость изменений будет не просто высокой, а не подъемной.
ИМХО с аналитиками это вопрос денег.
Есть деньги на сервера и OLAP-решения, то удобнее работать в них.
Нет. Используем «модные технологии», например Hadoop+Spark.
Есть только холивар gradle vs maven :-)
Плюс кодогенератор.
Плюс много чего.
А так JVM — мир изначально строился по Unix-филсофии.
Поэтому компилятор, сборщик, система управления библиотеками/зависимостями и IDE это отдельные приложения.
Это дает возможность комбинировать и встраивать в другие приложения.
В частности в CI/CD.
А комбайны… Ну Eclipse по началу пытался идти в этом направлении.
Как оказалось это никому особо не нужно.
MS тоже двигает Visual Studio Code. Это вроде бы «просто редактор»
Чтобы выходило 40 часов в неделю.
Особо не напрягало, но толку не было никакого.
Точнее толк был только, что по этому времени начисляли ЗП.
На продуктивность и решение задач никакого влияния не оказывало.
У меня сейчас проект который работает на Java не выше 1.7.79, на 1.7.80 уже не работает, не говоря о версиях выше.
Я пришел, когда вся команда «Встала ушла».
Документация устарела лет на 5. Тесты не работают года 3.
И команда ушла, когда разрабатывали «новую фичу».
Пришлось доделывать новую фичу. И запускать на проде.
Благо основа была норм. Но после 5 поколений программистов, там много накопилось технического долга.
Норм. Большинству коллективу пофиг.
«Страдал» только ПМ. :-)
:-)
Т.к. собеседовался в другую страну, то были проблемы с переводом денег мне.
Не смотря на то что не прошел, менеджер «заморочился» и полторы недели пытался перевести мне деньги.
Деньги перевели, хотя я не настаивал.
Задание было не сложным. Как сказали, мой кодестайл не удовлетворил.
Особых проблем нет.
Но в офисе мне легче работать.
Дома диван и холодильник постоянно отвлекают.
Жена и дети, кстати — нет.
Ребенку (3 года) спокойно объяснил, что папа работает. И он не мешает.
Жена играет с ребенком и дела по дому в другой комнате.
Но постоянно хочется «полежать, подумать». :-)
Как бы проблема шардинга, не должна касаться программистов, желательно, чтобы это была внутренняя кухня ДБА.
Здесь ТС рассматривает пайплайн для разработчиков.
Чтобы «отделить» программистов от ручных изменений в БД.
Т.к. все актуальные СУРБД к такому использованию приспособлены менее чем никак, то получается все очень неуклюже.
При этом — да, загрузка данных может быть и долгой.
Но обычно это не критично.
Когда конкуренты будут брать задёшево обычных крудоклепателей.
При этом результат будет один и тот же. :-)
Т.к. да в рамках рассмотрения одного электрона, все слишком неопределенно.
Но если рассматривать массу электронов, в проводнике, то в зависимости от поданного напряжения, будет прослеживаться какая-то закономерность.
То же самое и с коррупцией.
Если в рамках рассмотрения одного человека, это как бы проблема.
То в рамках общества, может оказаться, что проблемы нет вовсе, а есть возможности. :-)
Если к самому SQL у меня претензий не только, нет, а наоборот, чтобы для работы с реляционными данными использовали только его.
А вот что касается императивных расширения для SQL (PlSQL, TSQL, PgPlSQL), то я лично, против их повального использования (чаще всего бездумного).
Скажем так, я не раз оказывался в ситуации, когда приходил на легаси проект, а предыдущие программисты уже ушли. Из документации только код без тестов, какое-то ТЗ которое было актуально лет 5 назад и все.
Разбираться в портянках хранимых процедур, это чуть лучше, чем разбираться в исходных кодах программы на Clipper.
Тут в хотя бы нельзя просто сделать сомомодефицируемую процедуру.
Хотя это можно сделать, но нужно немного извратиться.
Проблема начинается, когда проект разрастается до такого размера, что нужна работа команды из более чем трех человек.
И тут системы командной работы для СУРБД в зачаточном состоянии.
Системы коллективной работы для других ЯП (JAVA, C#, Python и пр) очень плохо интегрируются с СУРБД.
По мне, писать логику БП в СУРБД, это закладывать мину в проект, которая рванет, через 1.5 — 2 года, когда сменится как минимум пара поколений программистов.
Стоимость изменений будет не просто высокой, а не подъемной.
Есть деньги на сервера и OLAP-решения, то удобнее работать в них.
Нет. Используем «модные технологии», например Hadoop+Spark.
В Германии лет 300-400 палками к порядку приучали.
Казахстан только в начале пути. :-)
Как бы последние события показывают, что это совсем не так. ;-)