И по какому признаку вы сделали вывод "машина на самом деле не видит"?

Оно самое, но теоретически без эксперта выделяет входные аналитики, и отбрасывает не рабочие. А так же не просит подкрепления верности итогового ответа от эксперта.

Вы профессиональный водолей, или че?

Каждое сообщение надо как загадку разгадывать

Прикиньте, у вас бы такой чел работал в конторе

я не делал, я ссылаюсь на заключения и работы ребят которые строят модели того, что машина видит, что бы она реагировала как этого хочет человек

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

Четкое отражение того что телеграм, то есть короткие сообщения и "мемчики" (естественно не культурные мемы), не подходят для обстоятельной беседы, пока мы не выйдем на одну волну. Где то, что я принимаю за ваше понимание некоторых частей, им и является. А у нас выходит недопонимание.

Отсюда кстати и вышел вопрос мем от мифа. Для меня различий нет. Его не видно. На этом в принципе все.

Не думаю, что формализация этого вопроса сильно облегчит дело. А может даже и вызвать отторжение. Если знаний у разработчиков не хватает, то неизменно будут проблемы с кодом. И они эти проблемы знают, и страдают из-за них. Это - хорошая точка входа. Нужно эти проблемы обнаружить (обычно это не сложно по косвенным признакам - сорванные сроки, концентрация багов, множественные переделки реализации и т.п.), и подсказать правильное решение. Две-три решенные таким образом проблемы, и они начнут сами спрашивать как лучше сделать. Но, чтобы это работало, нужно в совершенстве знать Software Design. Лично я не отделяю работу архитектора от Collaborative Development (т.е. распространения знаний), ибо если реализовать решение некому (в силу недостаточности квалификации), то какой смысл от этого решения?

Еще одна хорошая точка входа - споры на Code Review. Опять же, нужно в совершенстве знать Software Design и уметь убедительно аргументировать.

В общем, тут самое главное - сдвинуть этот клубок с места. Потом он наберет инерцию. Как я уже говорил, работа архитектора в команде - самоисключающая. Вначале команда будет обращаться с вопросами (тут самое главное сбалансировать по времени, ибо нужно успевать делать свою работу и не оставлять обращения без ответа), затем они научатся искать ответы на свои вопросы самостоятельно, и, в конечном итоге, станут автономны.

Чтобы сбалансировать по времени, нужно хорошо знать популярные reference applications, куда можно сослать посмотреть типовое решение, и каталоги рефакторинга, паттернов и т.п. Например, есть code samples EIP-паттернов к книгам. Это позволяет отвечать на вопросы быстро и исчерпывающе. Ну и, лучше один раз увидеть.

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

пока что у меня полное ощущение того, что вы разговариваете ради разговора

Всем привет! Ищу гостей в подкаст. Тема: Микросервисы, Event Sourcing, CQRS, DDD. Кто чувствует в себе нужное количество мидихлорианов, чтобы поговорить на эти темы - пишите =)

я всегда готов

Поиски гостей продолжаются =)

Напиши тут @iDDDqd

@ottotot а у вас нет желания про это поговорить? 😉 Фамилия знакомая по докладм =)

Да можно, а когда?

Напишу в личку