Фреймворк вроде бы позволяет ускорить процесс разработки в n раз. Но при этом:

1. Сначала нужно постичь все его тонкости и костыли. Обычно это происходит в процессе работы и даже одна фигня может занять легко пол дня. Но утешаешь себя мыслью что это только на первом проекте (на самом деле см. п. 2).
2. Фреймворки быстро устаревают. Новые версии объявляют депрекейтед привычные вам подходы и вводят новые. Фактически вам придется возвращаться к п. 1 снова и снова, в связи с чем экономия времени сомнительна.
3. Фреймворки часто избыточны для ваших задач и вам придется мириться с тормозами — пока оно загрузит 100500 общих библиотек или подобного.

В итоге вместо изучения вещей базовых — тратится время на изучение продукта жизнедеятельности тех или иных авторов. Надоело вкрай.

Какое решение?

Здравствуйте, Shmj, Вы писали:

S>Какое решение?

Постигнуть очевидную истину — фреймворк фреймворку рознь.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Постигнуть очевидную истину — фреймворк фреймворку рознь.

Давайте примеры правильных фреймворков.

Здравствуйте, Shmj, Вы писали:

НС>>Постигнуть очевидную истину — фреймворк фреймворку рознь.
S>Давайте примеры правильных фреймворков.

linq2db

Здравствуйте, Shmj, Вы писали:

S>В итоге вместо изучения вещей базовых — тратится время на изучение продукта жизнедеятельности тех или иных авторов. Надоело вкрай.

S>Какое решение?

Я от всех этих красивостей отказался в 2000 году.

Здравствуйте, Shmj, Вы писали:

S>Какое решение?

Проходил этот этап. Основное соображение — фреймворки ускоряют/удешевляют разработку и снижают требования к квалификации разработчиков. Почему это не золотая пуля, хорошо описано в вопросе.

Если же из тройки скорость-цена-качество упор требуется сделать на качество и немного на скорость, то берут команду сеньоров, которая собирает собственный "фреймворк" из готовых библиотек: выбираются либы отдельно для DI, конфигурации, HTTP сервера и клиента, сериализации, логгирования, мониторинга и т.д. И всё это увязывается в скелет приложения. Я считаю, что будущее именно за этим подходом, но есть ньюанс — нужен человек, знакомый с этим набором либ и обладающий достаточной квалификацией, чтобы писать приложения хорошо с нуля.

Один из ужасных типажей, который мне попадается на собеседованиях — квадратно-гнездовой фреймворщик: может рассказать про конфигурацию хибернейта, но не способен написать программу, сортирующую текстовый файл.

Здравствуйте, Shmj, Вы писали:

S>Фреймворк вроде бы позволяет....
S>В итоге вместо изучения вещей базовых — тратится время на изучение продукта жизнедеятельности тех или иных авторов. Надоело вкрай.

Даже без фрэймворков 99% времени — чтение чужого кода и чужих продуктов жизнедеятельности, а иногда даже своего кода. Пример: у меня есть крохотный проектик, который я написал примерно 3 года назад. Чтобы допилить туда небольшую фичу мне пришлось просидеть больше половины дня, разбираясь что там и как. Только после того как я разобрался и вспомнил, мне удалось написать туда вожделенные 100 строчек кода — до этого не понятно куда их там надо было писать и какие именно они должны быть.
Так вот, фрэймворки тебе позволяют быстрее разбираться в чужом коде (и в своём тоже) хотя-бы просто потому что тебе придётся читать в 10 и то дажи и 100 раз меньше кода, чем если бы фрэймворка не было. Фрэймворки уменьшают кол-во хаоса в проекте и значительно облегчают тебе жизнь при подходе к чужим (и своим тоже) творениям.

Здравствуйте, Shmj, Вы писали:

S>Фреймворк вроде бы позволяет ускорить процесс разработки в n раз. Но при этом:

S>В итоге вместо изучения вещей базовых — тратится время на изучение продукта жизнедеятельности тех или иных авторов. Надоело вкрай.

S>Какое решение?

А в любом случае придется изучать "продукта жизнедеятельности",
даже если один работаешь. Можно только сдвинуть чуть-чуть границу
твой код, чужой, но все равно большая часть того, что твоя программа
запустится и заработает зависит не от тебя (ОС, компилятор/интерпретатор,
стандартная библиотека твоего языка программирования и т.д. и т.п.).

И преимущество фреймворка, в том что из-за широты его использования
в разных проектах разными людьми его криво, косо можно заставить решить
большинство задач которые у тебя возникнут,
а вот собственная библиотека в этом смысле может потянуть на дно,
пара-тройка изменений в ТЗ, которые заставят отрефакторить
ее на 90%, и можно скатиться к тому, что большую часть времени
выполняются не задачи, а допиливыается своя библиотека, чтбы потом
выполнить поставленные задачи, но до реальных задача из ТЗ могут
руки и не дойти.

Здравствуйте, scf, Вы писали:

scf>Один из ужасных типажей, который мне попадается на собеседованиях — квадратно-гнездовой фреймворщик: может рассказать про конфигурацию хибернейта, но не способен написать программу, сортирующую текстовый файл.

Да, тоже слышал про чувака, который на любой практически вопрос приводил пример, какой метод из какой либы надо взять Тоже конечно важный скилл...

Здравствуйте, sambl74, Вы писали:

S>Да, тоже слышал про чувака, который на любой практически вопрос приводил пример, какой метод из какой либы надо взять Тоже конечно важный скилл...

Важный и полезный, но не заменяет умение программировать.

Здравствуйте, Shmj, Вы писали:

S>Какое решение?

Отказаться от фреймворков.

1. Пишем всё приложение с нуля (в уме).

2. Постепенно заменяем отдельные части приложения на библиотеки. Оцениваем плюсы-минусы каждой замены. Если минусов больше, то не заменяем.

Но для этого нужна соответствующая экосистема, где в наличии есть небольшие модульные библиотеки. Если в языке все пишут на фреймворках, с этим будут проблемы.

Я давно мечтаю написать для жавы эдакое переосмысление всей экосистемы. Начиная от инструмента сборки и заканчивая переписыванием всей стандартной мишуры — http, json и тд. Но вряд ли возьмусь, слишком много времени и практически гарантированно в ящик. Но думал много над этим.

Здравствуйте, vsb, Вы писали:

vsb>Я давно мечтаю написать для жавы эдакое переосмысление всей экосистемы. Начиная от инструмента сборки и заканчивая переписыванием всей стандартной мишуры — http, json и тд. Но вряд ли возьмусь, слишком много времени и практически гарантированно в ящик.

А самое главное — результат будет еще хуже чем то что есть сейчас.

S>1. Сначала нужно постичь все его тонкости и костыли
S>2. Фреймворки быстро устаревают
S>3. Фреймворки часто избыточны

JS — не язык, жабоскриптер — обычная веб-макака с клавиатурой, так что они должны страдать! Какое ещё тут "решение"??

Никогда вот не слышал, чтобы ругали .NET WF — нормальня такая платформа с шикарным C#. Может, всё же "инструменты имеют значение"? А то слышал от одних макак "инструменты под задачу", "хороший программист может писать на любом языке"! Маразм и тупость молодцеватых джунов. Язык имеет значение, ФВ тоже.

Здравствуйте, vsb, Вы писали:

vsb>Я давно мечтаю написать для жавы эдакое переосмысление всей экосистемы. Начиная от инструмента сборки и заканчивая переписыванием всей стандартной мишуры — http, json и тд. Но вряд ли возьмусь, слишком много времени и практически гарантированно в ящик. Но думал много над этим.

А надо? jdk-http — это отличный http клиент, jackson тоже близок к идеалу, mvn при всех своих недостатках отлично выполняет свою задачу. Можешь вкратце описать, как ты видишь дивный новый мир? Возможно, это уже запилено для более "продвинутых" языков.

Имхо, в java-мире всё уже изобретено, настоящие прорывы возможны только вместе с изменением языка. В Котлине и, особенно, в Скале много интересных инноваций и библиотек.

Здравствуйте, Kolesiki, Вы писали:

K>Никогда вот не слышал, чтобы ругали .NET WF — нормальня такая платформа с шикарным C#.

Вспомнилось: есть два типа языков программирования — те, кто все ругают, и те, которыми никто не пользуется.

Здравствуйте, Shmj, Вы писали:

Заколеблешься мультиплатыорменность поддерживать без фреймворков и движков

Здравствуйте, scf, Вы писали:

vsb>>Я давно мечтаю написать для жавы эдакое переосмысление всей экосистемы. Начиная от инструмента сборки и заканчивая переписыванием всей стандартной мишуры — http, json и тд. Но вряд ли возьмусь, слишком много времени и практически гарантированно в ящик. Но думал много над этим.

scf>А надо? jdk-http — это отличный http клиент

Против jdk ничего против не имею (ну если не считать старых классов из 90-х, но почти всему уже есть современная замена).

> jackson тоже близок к идеалу

Он неимоверно далёк от моего идеала. Парсинг json делается в несколько сотен строк. Форматирование жсон делается ещё короче. Это несколько килобайтов байткода. Сколько мегабайтов и десятков тысяч строк написано в жаксоне я не знаю, и знать не хочу.

> mvn при всех своих недостатках отлично выполняет свою задачу

А мне не нравятся недостатки.

> Можешь вкратце описать, как ты видишь дивный новый мир

1. Общее видение: максимальная простота. В том числе простота реализации Скорость там, где это не мешает простоте. Всё максимально же модуляризировано. Многие концепции вроде маппингов не нужны. Если ради простоты надо написать немного скучного кода, это нормально. Если ради удобного маппинга объектов на БД нужна библиотека на сто тысяч строк кода, значит разработчик будет сам писать маппинги, руками. А библиотека на несколько сотен строк даст ему удобный апи для этого, не более. В целом мне импонирует подход го. Можно это моё видение считать натягиванием мира го на жаву.

2. Использование native (graal). Всё должно быть оптимизировано под эту технологию. Рефлекшна не должно быть (ну по крайней мере там, где без него можно, а можно практически везде). JVM используется только во время разработки, чтобы не ждать компиляции.

3. Сборка. Для сборки проекта пишется отдельная программа-сборщик. С нуля её писать долго, поэтому предоставляется библиотека, которая делает удобным написание этой программы-сборщика. Что-то вроде build.gradle, только на жаве и попроще. Ну и какой-то cli, который автоматически компилирует этот скрипт, опционально делает его native (когда мы уже закончили писать скрипт и хотим просто его запускать). Конечная цель — чтобы с одной стороны написание скрипта не требовало изучение чего-либо кроме Java (ну и этой библиотеки, но опять же библиотека должна быть максимально неинтрузивной), с другой стороны чтобы сборка работала миллисекунды, а не десятки секунд.

4. Для отладки инструментарий для автоматической перекомпиляции изменённых файлов, перезагрузки классов и тд. В целом это есть для других фреймворков, тут ничего нового.

5. Для типовых веб-сервисов набор минималистичных библиотек, реализующих ровно то, что реализовывать самому скучно. HTTP, JSON тот же. Также обёртка вокруг JDBC, текущий API не очень хорош. Причём очень важно, чтобы реализация этих библиотек была простая, чтобы всегда можно было провалиться в реализацию и легко прочитать её. К примеру асинхронность не нужна, что убирает уйму сложности. В целом каждая отдельная библиотека должна занимать несколько тысяч строк от силы.

6. Ненужное — не нужно. HTTPS не нужен, все ставят реверс-прокси. Какие-то мегасуперпупер оптимизации не нужны, быстрей netty всё равно не сделаешь.

7. Использование последних стандартов, к примеру records и тд. В этом плане я жду некоторые фичи вроде string interpolation, которые могут очень круто сочетаться с тем же SQL.

Попробую свою идею выразить по-другому. Представь, что у тебя есть компилятор жавы и всё. Мавена нет. Спринга нет. Тебя заперли на год и тебе надо написать веб-сервис. Ты сначала пишешь тулзу для сборки на коленке, потом пишешь реализацию HTTP на коленке, потом неминуемо напишешь обёртку вокруг JDBC, вручную сериализацию и парсинг JSON. Потом ты напишешь второй проект, третий. Потом из этих трёх проектов попробуешь вытащить какие-то общие куски кода. Вот эти общие куски кода это и есть моё видение. Для типовых проектов, которые обрабатывают HTTP запросы и лезут в реляционную СУБД. По крайней мере для таких, с которыми я сталкиваюсь.

> Возможно, это уже запилено для более "продвинутых" языков.

Как я уже написал, в Го в целом это запилено. К сборке там другой подход, но мне любопытен именно мой вариант, мне он кажется интересным для исследования.

В целом моя проблема с популярными подходами в том, что 20% их кода решает 80% проблем, но они не останавливаются, а пишут ещё 80% кода, чтобы решить оставшиеся 20% проблем. Вот мне хотелось бы остановиться на первых 20%. Мне кажется, что это было бы в итоге лучше.

Здравствуйте, vsb, Вы писали:

vsb>В целом моя проблема с популярными подходами в том, что 20% их кода решает 80% проблем, но они не останавливаются, а пишут ещё 80% кода, чтобы решить оставшиеся 20% проблем. Вот мне хотелось бы остановиться на первых 20%. Мне кажется, что это было бы в итоге лучше.
Похоже ты хочешь просто сделать "не как у всех", а на выходе получится новый супер "кул-фреймворк" для стороннего наблюдателя (почти)ничем не отличающийся от spring/micronaut/whatever

Здравствуйте, vsb, Вы писали:

vsb>1. Общее видение: максимальная простота. В том числе простота реализации Скорость там, где это не мешает простоте. Всё максимально же модуляризировано. Многие концепции вроде маппингов не нужны. Если ради простоты надо написать немного скучного кода, это нормально. Если ради удобного маппинга объектов на БД нужна библиотека на сто тысяч строк кода, значит разработчик будет сам писать маппинги, руками. А библиотека на несколько сотен строк даст ему удобный апи для этого, не более. В целом мне импонирует подход го. Можно это моё видение считать натягиванием мира го на жаву.

В целом jvm мир дрейфует в эту сторону. На острие прогресса находится Scala — и атомарные библиотеки, и простота (местами). Даже до джавистов начинает доходить, что зачем нужны аннотации, если можно описать тот же функционал несколькими строками кода.

vsb>2. Использование native (graal). Всё должно быть оптимизировано под эту технологию. Рефлекшна не должно быть (ну по крайней мере там, где без него можно, а можно практически везде). JVM используется только во время разработки, чтобы не ждать компиляции.

А зачем? быстрее работать оно от этого не будет, разве что быстрее запускаться. Что важно разве что в aws lambda, но там JVM редко используют.

vsb>3. Сборка. Для сборки проекта пишется отдельная программа-сборщик. С нуля её писать долго, поэтому предоставляется библиотека, которая делает удобным написание этой программы-сборщика. Что-то вроде build.gradle, только на жаве и попроще. Ну и какой-то cli, который автоматически компилирует этот скрипт, опционально делает его native (когда мы уже закончили писать скрипт и хотим просто его запускать). Конечная цель — чтобы с одной стороны написание скрипта не требовало изучение чего-либо кроме Java (ну и этой библиотеки, но опять же библиотека должна быть максимально неинтрузивной), с другой стороны чтобы сборка работала миллисекунды, а не десятки секунд.

Тоже думал об этом, но, смотря на весь зоопарк билд тулов для самых разных языков, никто не смог осилить такой сборщик. Одна из причин — IDE нужно уметь извлекать метаданные из скрипта сборки для правильной работы intellisense. Может быть, получится у тебя.

vsb>4. Для отладки инструментарий для автоматической перекомпиляции изменённых файлов, перезагрузки классов и тд. В целом это есть для других фреймворков, тут ничего нового.

Это сложная и глючная штука. Сейчас популярен другой подход — писать приложения с минимальным временем старта и автоматически пересобирать/перезапускать их при изменении исходников.

vsb>5. Для типовых веб-сервисов набор минималистичных библиотек, реализующих ровно то, что реализовывать самому скучно. HTTP, JSON тот же. Также обёртка вокруг JDBC, текущий API не очень хорош. Причём очень важно, чтобы реализация этих библиотек была простая, чтобы всегда можно было провалиться в реализацию и легко прочитать её. К примеру асинхронность не нужна, что убирает уйму сложности. В целом каждая отдельная библиотека должна занимать несколько тысяч строк от силы.

Не все ли равно, сколько строк в библиотеке, если у неё минималистичный API и она работает? Например, HTTP очень объемный стандарт и даже JSON, при всей своей простоте, не так уж прост. Парсер JSON на токены и в jackson мог бы занимать несколько сотен строк, но дальше появляются ньюансы. Валидация с нормальным текстом ошибки (строка-колонка-описание), разнообразные фичи, не входящие в стандарт, но нужные людям (а-ля разрешить ключи без кавычек). Потом еще отдельная огромная механизация по десериализации в объект.

Тот же JDBC — он, на самом-то деле, неплох, если исплользовать его не из джавы, а из той же скалы или котлина.

vsb>В целом моя проблема с популярными подходами в том, что 20% их кода решает 80% проблем, но они не останавливаются, а пишут ещё 80% кода, чтобы решить оставшиеся 20% проблем. Вот мне хотелось бы остановиться на первых 20%. Мне кажется, что это было бы в итоге лучше.

Да, всё так и есть, минималистичные атомарные библиотеки, уже в Scala, когда-нибудь мода доберется и до джавы. Но вовсе не обязательно всё самому писать с нуля. Например, когда мне нужен HTTP клиент, я пишу к нему своё API ровно в том объеме, который мне нужен (паттерн фасад), и подключаю какую-нибудь реализацию. В итоге в моём коде нет избыточного API, я всегда свободен заменить реализацию (в том числе на фейковую для тестов), мне не нужно всё делать самому с нуля и при этом у меня остается такая опция.

Проблема в том, что язык формирует мышление. Без поддержки лямбд сложно объяснить, что map/flatMap — это хорошая идея. Если нельзя в одном классе объявить всю доменную модель, то тяжко писать фасады для стороннего кода. Если язык не поддерживает именнованных параметров методов и конструкторов, то сложно заставить себя писать модели и конверторы между ними.
Я бы посоветовал посмотреть на Scala и их библиотеки. Там хватает своих проблем, но направление правильное.

Здравствуйте, vsb, Вы писали:

vsb>>>Я давно мечтаю написать для жавы эдакое переосмысление всей экосистемы.

А я себе написал для Scala. Перевел команду (уже не одну). Все успешно работает в production. Теперь потихоньку пишу open source на Scala 3.

vsb>Парсинг json делается в несколько сотен строк.

Json — это сложно. Не в смысле "как-то распарсить", а в смысле сделать правильно и модульно. И так, чтобы в модулях было минимум функциональности и ничего лишнего? Например, тот же парсер Json должен только уметь парсить Json. И не делать ничего лишнего вроде создания Object Model (может, я валидатор пишу?). При этом нужно решить, что делать для опциональных фичей вроде комментариев. Потом к этому всему прикрутить ввод (не парсерское это дело — заниматься вводом). А еще, наверное, нужно строить какую-то модель. Только не совсем понятно, какую. Потому-что требования разные.

Например, реальный список, от которого хочется абстрагироваться в парсере:

• Построение любой объектной модели. Хотя бы просто потому, что сложно сделать универсальную. Например, для обработки всяких конфигов (и прочих подобных штук) мне очень бы хотелось иметь позицию элемента в исходном файле. Я хочу уметь выводить "значение параметра равно 42, потому что он определен в файле XYZ (и переопределяет значение 12, определенное в ZYX)". В других случаях будет достаточно только самих данных.
  
• Примерно по тем-же причинам хотелось бы абстрагироваться от конкретных сообщений об ошибках. В ряде случаев это может быть location + code (для компьютеров), в других — просто текст. В третих — вообще подробностей не надо.
  
• Ввод-вывод. Я хочу не только рекурсивный pull-парсер. Я хочу нерекурсивный pull-парсер. Или даже нет, я хочу парсер, в который можно кормить ввод блоками! И это даже не полностью абстрактная задача. Это можно использовать в асинхронных сервлетах Jetty. Не накапливать весь ввод, а парсить прямо на ходу.
  
• Ну и опциональные комментарии в json. Фича бесполезная, но с точки зрения задачи дизайна — интересная.

И обратите внимание — все вышеперечисленное ничего к синтаксису json не имеет! Хочется везде использовать один и тот же проверенный парсер.

Я вроде придумал границы, теперь собираю кирпичики. Теперь парсер как в анекдоте — может парсить в объекты. А может не парсить (тесты парсера как раз упал/не упал). И я себе сделал кирпичик для "push-парсера".

>> Можешь вкратце описать, как ты видишь дивный новый мир
vsb>1. Общее видение: максимальная простота. ... Если ради удобного маппинга объектов на БД нужна библиотека на сто тысяч строк кода, значит разработчик будет сам писать маппинги, руками.

Это хорошо. Но для маппингов нужна очень хорошая машинерия. Тоже из реальных сценариев. Нам пришел JSON. Он валиден (с точки зрения грамматики) но не ложится в схему объектов. Хотелось-бы не упасть на первой ошибке (а может, хотелось бы!), а собрать и выдасть сразу несколько. Сколько — сложно сказать. Может — все, может — часть. Я такое тоже умею, это несложно. Но там аппликативы в полный рост (и еще немного монад).

vsb>2. Использование native (graal). Всё должно быть оптимизировано под эту технологию. Рефлекшна не должно быть (ну по крайней мере там, где без него можно, а можно практически везде).

Ну... Смысла оптимизироваться под грааль для своих проектов я не видел. Но рефлексии нет (и макросы тоже не используются) — не люблю. Так что можно было бы и в грааль собирать.


vsb>3. Сборка. Для сборки проекта пишется отдельная программа-сборщик.
vsb>4. Для отладки инструментарий для автоматической перекомпиляции изменённых файлов, перезагрузки классов и тд. В целом это есть для других фреймворков, тут ничего нового.

sbt

vsb>5. Для типовых веб-сервисов набор минималистичных библиотек, реализующих ровно то, что реализовывать самому скучно. HTTP, JSON тот же.

Для транспорта я взял embedded Jetty, даже без сервлетов. Маршрутизация — тупой pattern-matching с парой утилит (например, чтобы списки поддерживаемых глаголов генерировать в ответах). Туда же по ситуации дописывается то, что нужно. Например, маршрутизация/парсинг по заголовку Accept. В зависимости от него могут вытаскиваться "плоские" объекты, а могут — с делатями. Желаемые форматы данных в параметрах запроса — вчерашний день. Json — свой. HTTP — пока не свой. Интересно, но много и приоритеты совсем другие. В целом ничего плохого про Jetty Http сказать не могу.

vsb> Также обёртка вокруг JDBC, текущий API не очень хорош.

Тоже сделал. Позволяет писать код в виде

case class Something(id: Long, a: Int, b: String)

def getSomething(a: Int): Option[Something] =
  sql"""
    SELECT *
    FROM somethings
    WHERE a = ${a}
  """ select optional(something)

def something(rs: ResultRow): Something = 
  Something(rs.id, rs.a, rs.b)

Безопасно (без SQL Injection). Она не конкатенирует строки а использует JDBC. Если скормите в интерполяцию что-нибудь неудобоваримое (например, Thread), ругнется во время компиляции. Хотя если напишете адаптер — не ругнется (никаких глобальных переменных! Все адаптеры должны быть видны в лексическом контексте). Вроде бы последняя версия даже умеет во время компиляции (на системе типов) проверять уровень изоляции транзакции. Т.е. если метод требует Serializable-изоляции, то в контексте RepeatableRead вы его не вызовете.

vsb> Причём очень важно, чтобы реализация этих библиотек была простая, чтобы всегда можно было провалиться в реализацию и легко прочитать её.

Sql (но без нормальной документации) Можете оценить сами. Нужно знать Scala (как минимум — implicits и интерполяции). Вроде там больше ничего не используется. Могу поделиться JSON, но там нужно немножко (ну ладно, множко) уметь монады и тайпклассы. Но в целом тоже ничего сложного (хотя низкоуровневое API парсеров мне пока самому не нравится).

vsb> К примеру асинхронность не нужна, что убирает уйму сложности.

В реальных задачах — нужна. Иначе все совсем грустно масштабируется. И есть вторая проблема. Если вы не можете универсально асинхронность, то будут и большие проблемы с мониторингом. Те же метрики собирать вручную. И еще параллельно протаскивать контекст для распределенной трассировки. И не забывать его обновлять на "внутренних границах" (потокоглобальные переменные — это не круто же!). Вот если все на тайпклассах, можно уровни достаточно прозрачно менять. Я недавно добавлял distributed tracing к набору библиотек. Для большинства прикладного кода это выражалось просто в замене сервера (точнее, небольшой интеграции обработчиков) на тот, который поддерживает интеграцию с трассировкой. И еще пару реализаций монад в коде приложения сменить (это тоже в main). Остальное — само. Оно еще метрики (можно и performance включить если надо) там же на автомате собриает. "Интересные места" тоже расставляются вручную, но более-менее простым API.

vsb>В целом моя проблема с популярными подходами в том, что 20% их кода решает 80% проблем, но они не останавливаются, а пишут ещё 80% кода, чтобы решить оставшиеся 20% проблем.

Вы еще забыли про дополнительные 30% проблем, которые создаются 20% кода, решающего 80% проблем. Просто потому, что какие-то места во фреймворке оказались прибиты шурупами, а мне очень-очень надо