Код читает только программист и компилятор, всё

Читают новые разработчки команды, плюс разработчики другой команды при передаче сервиса в другую команду

тут еще стоит заметить про agile команды,  из удобно переформировывать под текущие потребности бизнес-плана компании. команда разработки это нестабиьная во времени сущность.

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

Привет! знакомый переслал вакансию. вдруг кому-то интересно.
в Мюнхене одна компания ищет Lead Software Architect с опытом в IoT platforms for industrial application.

Вот описание проекта:
The overarching goal of the research project REMORA – Multi Stage Automated Continuous Delivery for AI-based Software & Service Development in Industry 4.0 is to drastically shorten today’s expensive AI development processes for industrial applications, generating added value and driving more widespread use of AI.

Central focus of the research:
* High-quality industrial data
* Robustness of algorithms
* Dynamic adaptation of data streams and analytic models

To leverage data science and AI, systems must be capable of generating high-quality data. This must be done directly at the point of data origin. The quality of the data must be assured during the continual process for dynamic acquisition, processing, and analysis of data.
The robustness of algorithms is determined by their capability to be „dynamic“. It’s practically impossible to modify current analytic models/algorithms and data architectures on the-fly, which makes them unsuited to real-world production environments. Dynamic algorithms must be able to ask for more/other/additional data or some how react to what happens in the reality.
Dynamic adaption of data and analytic models will allow us to shift process complexity to where it can be handled most efficiently and not to be static.

REMORA will use results from the proposed project to develop microservices that ensure automated, efficient, and profitable integration of data science and AI for
enterprises active in the field of automation.

Вот здесь https://t.me/itarchitect_jobs специальная группа для  вакансии

А еще сотрудник внедрения, третья линия поддержки у вендора, третья линия поддержки у клиента и дофига других человек.

Вдогонку к разговору о том, что из кода мол всё понятно. Давайте я на sql напишу, т.к. его то все знают:

CREATE TABLE F123_qf(
    ID int,
    Name varchar(255),
    Memo varchar(255),
    External int,
    ParentID int,
    Category varchar(255)
);

Кто и что здесь понял?

Только что ревью этот скрипт скорее всего не пройдет )

Ну, а если мы размажем семантику по названием полей и таблиц, станет ли заметно лучше? Таблицу назовем, например, Person - разве понятней будет?

Немножко понятней. По идее должны быть в дев.конторе принципы наименования сущностей, атрибутов. С этой структурой наверное еще и код работает, а для кода идеально еще актуальные юнит-тесты.  Тогда намного понятней

MSA вам подкинет злую шутку: Person без контекста сервиса может означать что угодно. Во можестве сервисов может быть Person и означать совершенно разное.

Нет, ну назвать таблицу things -  было бы явным перебором :)

Если у нас есть MSA и описанные сервисы тогда я сходу не могу ухватить пока, зачем мы лезем системе в кишки и хотим понимать этот скрипт.

Есть такая штука: EIF - European Interoperability Framework В ней, в частности, интероперабельность рассматривается на разных уровнях: технологический, семантический, ... https://joinup.ec.europa.eu/collection/nifo-national-interoperability-framework-observatory/3-interoperability-layers#3.5 Пять уровней может и перебор, но одной технологической интеоперабельности, точно недостаточно

У меня вот только сегодня возникло в рассмотрении два разных типа "Тип заявителя" для разных видов обращений. Да, кстати, есть еще типы и виды... В общем, без четкой инфы о том, где какой тип используется, теряется и сопровод, и команда развития.

Это норм. У нас message type в одном сообщении на двух уровнях есть. И ещё сверху HTTP-шный...

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

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

Кстати, по поводу DDD. Да не поймут меня неправильно пламенные приверженцы этого популярного подхода. Я бы в названиях методов и классов старался бы максимально задирать уровень абстракции. Ну и вообще, писать максимально абстрактные вещи, которые легко реюзать. Понимаю, что это другой подход. Но иногда и он полезен. Впрочем, это уже обсуждалось вот здесь в комментах:  https://wp.me/pRljZ-f4 лет десять назад