да, тоже замечал. Очень сильные ребята долго читают код перед тем, как провести ревью, медленно и коряво формулируют причины ошибок и улучшений, но если слушать, что хотели сказать, а не англоязычные теги, оказывается, что у них более взвешенное и глубокое мышление. В том году нанимал; оба сеньора, которые пришли, ни разу не сказали ни слово паттерн, ни его название. Но зато ошибку дизайна (BE) разглядели в первую очередь.
Всегда ли, когда вы видите, что сотрудник или коллега делает что‑то не так, вы даёте ему негативную обратную связь?
Если хто просто рабочий момент, то более лёгкий вариант в чате в ЛС, более тяжёлый вариант - лично сказать, позвав попить кофе или после обеда. Может быть критическая ошибка, редко, тогда я показываю в чате группы с обоснованием, почему это совсем х*, и не надо так делать вообще никогда. Резко негативные примеры должны видеть все. Возможно, неплохо бы это предворять личным разговором, но, бывает, физически нет времени на дублирование сигналов и скругление углов. Самое молодое поколение может такое воспринять плохо.
В целом - почти всегда стараюсь, в основном распространялось на подчинённых.
Если на предыдущий вопрос вы ответили «не всегда», то что является основным барьером?
Не даю если некритическая ошибка у коллеги, который от меня не зависит или на которого не могу повлиять. Может быть лень или плохое настроение просто. Разные причины.
А как вы поступаете, когда вас критикуют?
Смотря кто и как. В адекватных ситуациях стараюсь адекватно, в конструктивных - конструктивно. Часто заканчивается замятием после моих уточняющих вопросов. Начиная критику не все готовы к конструктиву.
Какую критику и от кого вы сейчас не готовы воспринимать?
От глупых хамов и самодуров. И завтра не готов буду.
1. Воспринимайте эмоции других как сигналы об их выходе из зоны безопасности — так они защищаются.
1.5 Столкнувшись с проявлениями таких защитных эмоций, задайте себе вопрос: "а что он этим говорит? ", "какие у него интересы? ". Информацию, как вы подметили, дают, не только конструктивные ответы, но мимика, настроение, эмоции. И вот, если, например, превалирует подавленное, угнетённое состояние или раздражительность - это уже сигнал, и он, скорее всего, до этого разговора есть.
2.Столкнувшись с проявлениями таких защитных эмоций, задайте себе вопрос «Чего я хочу НА САМОМ ДЕЛЕ?».
"Где-то" LLM действительно может штамповать сервисы, а у нас конкретно - куча НФТ, так что без локальной/корпоративной LLM с хорошими ресурсами не обойтись. В любом случае это вопрос, может и недалёкого, но будущего.
ИИ - вообще отдельная тема. Сейчас провожу эксперимент, начал писать статью. Пока скептически отношусь. Может, удастся сделать полезные выводы. Многое, понятное дело, упирается в ресурсы.
На текущий момент мы не можем полностью автоматизировать. Проекты в каком-то необычном гибридном состоянии. Мы с коллегами пытаемся заранее чуть "подстелить соломки". Я в прошлом году, например, отфильтровывал с рынка сильных профессионалов, о чем писал статьи,- даже при наличии материальных ресурсов кому-то надо отслеживать и валидировать результаты, когда внезапно накроет светлым будущим.
Пока что работаем через высокую планку входа и попытки формализации архитектурных нюансов. Время покажет, насколько оправдано. Имхо, результат, каким бы то ни был, покажется в ближайший год.
Лига цифровой экономики например, на федеральных проектах. Лет 7 назад уже использовали. Не на что, так не на что. Компания с 5000 сотрудников может ошибаться, именно поэтому развиваются и растут.
Нет, цитата о половине пустых слоев не от меня. И у меня в продуктовом коде не так. У каждого слоя свое предназначение, разделение по зоне ответственности даже для людей : что-то правит разработчик, что-то аналитик.
И не пытался учить, нет таких целей. Я рассказываю, как делают у меня на проекте. Кто не понимает подходов - волен реализовывать все в одном методе.
Нет, не три слоя.
В openapi наборы ямлов от аналитиков и архитекторов, каждый может отвечать за свою часть, дальше арх. надзор , аппрув и компиляция в общий openapi, по которому отрабатывает openapi-generator. Это полноценный слой, в котором работают только аналитики и архитекторы. Код там ямлы, который они собирают. В этом же слое, при необходимости, можно настроить генерацию схемы для документации.
В asyncapi ямл и dto. В зависимости от микросервиса и особенностей стека эти dto contract first или написаны разработчиком. Могут быть вспомогательные классы при необходимости. Цель слоя-публикация артефакта в нексус и фиксация контракта. Возможна гибкость. При наличии доп. кода юнит-тесты, обычно нет или мало.
Api - слой со сгенерированными классами для обмена, тоже могут быть вспомогательные классы, тоже нужно для публикации.
Как тут вообще люди считают? То половина пустых слоев, то три.
Да, местами сложность уходит в бюрократию, потом в легаси, а потом в заморозку релизов.
Насчет того, что архитектура прям-таки уходит в большую простоту - не могу согласиться: по-разному бывает. В разных компаниях и на разных стеках я видел диаметрально противоположные подходы буквально ко всему. И везде были аргументы.
Когда-то я в противовес этой хореографии и слоям реализовывал SOA без оркестратора и брокера, на шине. Ещё раньше - серверную часть на БД. И трёхслойку по библии Эванса делал. И двухязычный монолит. Архитектур - море. Как фломастеров.
Есть здравые мысли. Американцы, вообще-то, продвигают такие подходы. Тот же г-н Эванс.
Для менее квалифицированного русского коммюнити такие подходы, пожалуй, сложноваты. Я писал похожий архитектурный разбор реальных проектов, заминусили и отписались:
Я не понимаю ничего в DDD, зачем вы столько воды льете, толку ноль.
Вообще слоистость +- в таком виде уже больше 7 лет работает в энтерпрайзе в разных компаниях.
Но, блин, у вас минимум в двух курсах аналитик, тестировщик и автор статьи не общаются друг с другом, видны дыры между теорией, практикой и автотестами. Заставьте этих людей поговорить, у вас же телемост даже есть. Новичкам такое несоответствие взрывает мозги, они бросают курсы. Деньги-то вы все равно получите, но люди получают фикцию, не надо так.
А вот эмуляция аджайла зачётная. Только группы стажёров у вас не самоорганизуются, надо управлять процессами, назначив кого-то из своих лидом или ПО, называйте как хотите.
Предложения?
Хороший вопрос! Я тоже спрашивал разницу между протоколами SOAP и REST.
да, тоже замечал. Очень сильные ребята долго читают код перед тем, как провести ревью, медленно и коряво формулируют причины ошибок и улучшений, но если слушать, что хотели сказать, а не англоязычные теги, оказывается, что у них более взвешенное и глубокое мышление. В том году нанимал; оба сеньора, которые пришли, ни разу не сказали ни слово паттерн, ни его название. Но зато ошибку дизайна (BE) разглядели в первую очередь.
Разумеется. Поэтому есть фильтр конструктивности.
Изредка бывает эмоционально и неадекватно, но с долей конструктивности. Когда междометия между криками дают информацию.
Все равно не серебряная пуля.
Если хто просто рабочий момент, то более лёгкий вариант в чате в ЛС, более тяжёлый вариант - лично сказать, позвав попить кофе или после обеда. Может быть критическая ошибка, редко, тогда я показываю в чате группы с обоснованием, почему это совсем х*, и не надо так делать вообще никогда. Резко негативные примеры должны видеть все. Возможно, неплохо бы это предворять личным разговором, но, бывает, физически нет времени на дублирование сигналов и скругление углов. Самое молодое поколение может такое воспринять плохо.
В целом - почти всегда стараюсь, в основном распространялось на подчинённых.
Не даю если некритическая ошибка у коллеги, который от меня не зависит или на которого не могу повлиять. Может быть лень или плохое настроение просто. Разные причины.
Смотря кто и как. В адекватных ситуациях стараюсь адекватно, в конструктивных - конструктивно. Часто заканчивается замятием после моих уточняющих вопросов. Начиная критику не все готовы к конструктиву.
От глупых хамов и самодуров. И завтра не готов буду.
Интересные мысли.
Но я бы добавил пункт 1.5
1.5 Столкнувшись с проявлениями таких защитных эмоций, задайте себе вопрос: "а что он этим говорит? ", "какие у него интересы? ". Информацию, как вы подметили, дают, не только конструктивные ответы, но мимика, настроение, эмоции. И вот, если, например, превалирует подавленное, угнетённое состояние или раздражительность - это уже сигнал, и он, скорее всего, до этого разговора есть.
1 Да, но тут тонкие политические моменты. Их документации изучались аналитиками неск. лет назад.
2 Да, может и так, но тут как говорится, "всё решено до нас".
"Где-то" LLM действительно может штамповать сервисы, а у нас конкретно - куча НФТ, так что без локальной/корпоративной LLM с хорошими ресурсами не обойтись. В любом случае это вопрос, может и недалёкого, но будущего.
ИИ - вообще отдельная тема. Сейчас провожу эксперимент, начал писать статью. Пока скептически отношусь. Может, удастся сделать полезные выводы. Многое, понятное дело, упирается в ресурсы.
На текущий момент мы не можем полностью автоматизировать. Проекты в каком-то необычном гибридном состоянии. Мы с коллегами пытаемся заранее чуть "подстелить соломки". Я в прошлом году, например, отфильтровывал с рынка сильных профессионалов, о чем писал статьи,- даже при наличии материальных ресурсов кому-то надо отслеживать и валидировать результаты, когда внезапно накроет светлым будущим.
Пока что работаем через высокую планку входа и попытки формализации архитектурных нюансов. Время покажет, насколько оправдано. Имхо, результат, каким бы то ни был, покажется в ближайший год.
Лига цифровой экономики например, на федеральных проектах. Лет 7 назад уже использовали. Не на что, так не на что. Компания с 5000 сотрудников может ошибаться, именно поэтому развиваются и растут.
Я же названия конкретные писал. Названия выдуманные? Серьёзно? Можно устроиться на работу, если возьмут, посмотреть всё изнутри.
Нет, цитата о половине пустых слоев не от меня. И у меня в продуктовом коде не так. У каждого слоя свое предназначение, разделение по зоне ответственности даже для людей : что-то правит разработчик, что-то аналитик.
Код может и да. Но ошибки аналитики, проектирования, контрактов.
И не пытался учить, нет таких целей. Я рассказываю, как делают у меня на проекте. Кто не понимает подходов - волен реализовывать все в одном методе.
Нет, не три слоя.
В openapi наборы ямлов от аналитиков и архитекторов, каждый может отвечать за свою часть, дальше арх. надзор , аппрув и компиляция в общий openapi, по которому отрабатывает openapi-generator. Это полноценный слой, в котором работают только аналитики и архитекторы. Код там ямлы, который они собирают. В этом же слое, при необходимости, можно настроить генерацию схемы для документации.
В asyncapi ямл и dto. В зависимости от микросервиса и особенностей стека эти dto contract first или написаны разработчиком. Могут быть вспомогательные классы при необходимости. Цель слоя-публикация артефакта в нексус и фиксация контракта. Возможна гибкость. При наличии доп. кода юнит-тесты, обычно нет или мало.
Api - слой со сгенерированными классами для обмена, тоже могут быть вспомогательные классы, тоже нужно для публикации.
Как тут вообще люди считают? То половина пустых слоев, то три.
Да, так и есть. Сейчас вот уже второй год пробуем работать по книгам о чистоте.
Да, местами сложность уходит в бюрократию, потом в легаси, а потом в заморозку релизов.
Насчет того, что архитектура прям-таки уходит в большую простоту - не могу согласиться: по-разному бывает. В разных компаниях и на разных стеках я видел диаметрально противоположные подходы буквально ко всему. И везде были аргументы.
Когда-то я в противовес этой хореографии и слоям реализовывал SOA без оркестратора и брокера, на шине. Ещё раньше - серверную часть на БД. И трёхслойку по библии Эванса делал. И двухязычный монолит. Архитектур - море. Как фломастеров.
Да, это NDA и свои гитлабы. Разве не так делают крупные компании?
Лига цифровой экономики, например. Некоторые проекты зелёного банка. Мой холдинг использует.
У нас разве холдинги публикуют в публичные репозитории исходный код сервисов?
А какие именно публикации? Есть литература, в основном англоязычная, можно посмотреть на медиуме, реддите, и даже на хабре.
Нужно подтверждение, что в амазоне и ibm используют такие подходы? Я без понятия, не читал их публикации последнее время.
Есть здравые мысли. Американцы, вообще-то, продвигают такие подходы. Тот же г-н Эванс.
Для менее квалифицированного русского коммюнити такие подходы, пожалуй, сложноваты. Я писал похожий архитектурный разбор реальных проектов, заминусили и отписались:
Вообще слоистость +- в таком виде уже больше 7 лет работает в энтерпрайзе в разных компаниях.
О, у вас такая же статья для решётки.
Не знал, насколько onion популярен в других ЯП.
В предыдущих коммантариях отвечал. Если кратко - это решение "сверху".
Постарались получить плюсы от такого подхода.
Вроде в кризис джунов вещь хорошая.
Но, блин, у вас минимум в двух курсах аналитик, тестировщик и автор статьи не общаются друг с другом, видны дыры между теорией, практикой и автотестами. Заставьте этих людей поговорить, у вас же телемост даже есть. Новичкам такое несоответствие взрывает мозги, они бросают курсы. Деньги-то вы все равно получите, но люди получают фикцию, не надо так.
А вот эмуляция аджайла зачётная. Только группы стажёров у вас не самоорганизуются, надо управлять процессами, назначив кого-то из своих лидом или ПО, называйте как хотите.