Если это воспринимать как метафору, т.е. "DDD - это как микросервисная архитектура, но для наших ментальных моделей, отражаемых в коде, а не для самого кода и его технологической обвязки", то это довольно удачная метафора, не описывает все DDD, но указывает на ключевые вещи. Но у вас в статье получилось слишком буквальное сравнение, что понятно - вы старались донести действительно удачную метафору. Все возражения как мне кажется по поводу этой буквальности. Но для начала обсуждения неплохо. Скажем вы пишете в ответе на другой коммент: "И не превратится ли это "много" в очередную монструозную систему на базе кубера?" - хороший вопрос! Но бывают действительно сложные предметные области, в которых тесно переплетены многие сущности. И ведь именно для таких областей наши информационные системы могут оказаться особенно полезны - если мы хоть немного помогли справиться со сложностью, то мы герои. И вот для таких сложных случаев и нужны, скажем, паттерны из "синей книги" - там ведь не только про то, что надо разделять и властвовать, но и про связи между компонентами - как добавлять эти связи так, чтобы не получилось "монструозного кубера". На ютубе есть выступление Эванса как раз про микросервисы и DDD кстати.
Вы просто не улавливаете определенных культурных особенностей, формально вы все правильно пишете, и более того, описанные вами в первой статье приемы работают, но не оптимальны, вы просто, извините, задолбаетесь так работать, выгорите еще до первого повышения xD Да, решать вопросы с привлечением руководителя - это "против лома нет приема", но это долго. Красный цвет действует, но когда в ваших сообщениях все к нему привыкнут и перестанут замечать, как вы будете дальше писать - красным жирным капсом? xD И так далее. Но с другой стороны, чем больше вы будете упорствовать в своей стратегии, тем быстрее набьете нужное число шишек, чтобы ее поменять, и поскольку вы джун, то для вас это естественно. И даже не странно для джуна писать статьи о том, чего он не понимает - для вас естественно не понимать, что вы не понимаете xD Но вот что мы это читаем и возмущенно комментируем - это поистине странно. Но так, видимо, работают медиа - чем дебильней и несущественней обсуждение, тем больше желания к нему присоединиться xD
Можете не читать Agile Manifesto, а прочесть только список его "подписантов" и подумать о том, много ли среди них "бизнеса". Аджайл придумали разработчики успешных проектов (а вовсе не бизнес), которым пришлось реализовывать массу новых фич, поток которых был обусловлен успехом проектов. Затем он был подхвачен "стартап-культурой", у которой были аналогичные запросы.
Скорее всего в том типе компании, которую описывает автор поста, после такой просьбы к руководителю вам предстоит еще общение с вашим руководителем на тему "а все ли у вас в порядке, а уверены ли вы, что без чрезмерного труда справляетесь с рабочими задачами" и потом, вероятно, также общение с сотрудником HR-отдела на ту же тему, возможно с "очной ставкой" с этим самым человеком, с которым вы отказались работать. Потому что конечно же для более-менее отлаженной организации отказываться с кем-либо работать не то чтобы ненормально, но вызывает большие напряжения у менеджмента, который начинает переживать, что не все отлажено. Причем ваш руководитель будет понимать, что за той же инфой аналитик придет к нему, если вы откажетесь с ним общаться, так что вашему руководителю будет гораздо удобнее наладить ваше взаимодействие с аналитиком.
Ответом по существу будет "отказать с объяснением, почему отказано", тогда и поход к руководителю, возможно, не нужен будет. Задача аналитика, который к вам пришел, - сделать так, чтобы вам выгоднее было выдать максимум информации, чтобы от вас отвязались. Ведь его работа - собирать и агрегировать инфу, и в особенности на ранних этапах профессионального развития ему важно с вас стрясти максимум информации, чтобы как нейросеть на ее объеме обучаться.
Руководитель, кстати, скорее встанет тут на сторону аналитика по той же причине, - ему проще выдать аналитику максимум инфы, чтобы не менеджерить общение с ним до бесконечности, и потом получить адекватные требования для подготовки задач в работу, потому что от аналитиков в первую очередь зависит качество требований.
Понятно, что любой адекватный человек не мечтает о том, чтобы другим было с ним неприятно общаться. Но в конечном-то итоге если вы таким образом избегаете ответа по существу, то к вам все равно потом придут, но с вашим руководителем. И именно зная это вы скорее всего и не отмахнетесь.
Ваши "гори в аду" как раз показывают, что это работает и вы будете неспособны это проигнорировать, особенно четвертый пункт, но ведь автор статьи дает советв не вам, а тому, кто с вами взаимодействует. В большой корпорации без некоторой доли работы локтями никак. И да, встреча с руководителем решает проблему с переадресацией.
Есть задачи, по которым все вами выше сказанное справедливо, а есть те, по которым сроки очевидны или даже приняты как обязательства. Если вы о задаче первого типа напишете то, что написали выше, то вполне "подскажете по срокам", вы дадите свою оценку неопределенности для задачи и покажете, каков текущий этап работы над ней.
Какая-то агитка вместо статьи. Не разрабатываю для мобилок и не имею симпатий ни к нативным инструментам, ни к инструментам типа Flutter, но статья кажется пытается скорее рекламировать, чем информировать.
Я работал на удаленке сначала за 7 часовых поясов в одну сторону, потом 5 часовых поясов в другую, каждый раз основная часть команды была не в моем поясе, и как-то норм.
Пытаюсь представить кого-то из аудитории Хабра, кто испытывает настолько сильный гнев и единственный способ решения проблемы - регулярные пробежки. Какой-нибудь программист "системы взимания платы" Платон, ненавидящий коррумпированных боссов? Заказчик второсортного аутсорсера, пофейлившего все сроки? (Я работал на таком проекте, к моменту моего прихода все сроки были уже безнадежно пофейлены, причем заказчик был весьма и весьма престижной западной компанией и они продолжали с нами работать! Подозреваю, что возможно решали эмоциональные проблемы пробежками как раз, лол)
Если у вас дейли скрам занимает по полчаса, то вы вероятно не видели нормально работающую по скраму команду и попросту представляете, что такое скрам, скорее формально. Однако если бы команда и была работающая по скраму, я бы не называл прирост эффективности работы главной целью скрама - в реальности он нужен для предсказуемости результатов работы команд для менеджмента, т.е. для большей управляемости процесса разработки. Если в этой части вы не добились результатов - увольте или подайте в суд на тех, кто внедрял вам скрам.
Знающие люди советуют в таких случаях пользоваться паттерном State от GoF, вот здесь есть пример, который кажется похож на на вашу ситуацию, но без всякой логики в сервисах.
Фендер от гибсона при сопоставимом пути сигнала можно отличить, хамбакеры от синглов все-таки отличаются значительно (предположим что под фендером понимается страт или телекастер, а под гибсоном - Les Paul и что на фендере при записи был включен хотя бы один сингл). В коргах и ямахах, если говорить скажем о 1980-х, использовались разные механизмы синтеза (скажем Ямаха стала сильно топить в FM в какой-то момент, а Корг с Роландом и прочими развивали PWM и phase distortion) и они конечно звучат по-разному. Вот это для аудиофила как раз интересно, отражает историю музыки в ее связи с историей технологий, показывает, как разные музыканты использовали возможности и ограничения доступных им технологий и т.п.
Не уверен, что русское слово "модуль" в переводе используется удачно, модули могут использоваться и без намерения создавать семейство продуктов. Во многих энтерпрайз-системах логирование или аналитика выделены в отдельный модуль, но не потому что всерьез предполагается его замена в случае изменившихся требований, а просто потому что его не хочется собирать и деплоить с каждым релизом.
Насчет "не переиспользовать код" вы невнимательно прочли, ключевое место там:
Мы не предлагаем отказаться от создания многократно используемых активов — скорее необходимо постоянно проверять, что они по-прежнему полезны. В случае с PenultimateWidgets, как только архитекторы поняли, что компонент является узким местом, они разорвали точку сцепления.
Это довольно часто встречающаяся ситуация, когда много разных сценариев использования проходят через один компонент, который сначала кажется весьма полезным (и является полезным в какой-то степени), но потом становится бутылочным горлышком с точки зрения поддержки. В этих случаях нужно просто отказаться от логики "у нас уже есть компонент с 90% нужного функционала, поэтому нужно обязательно использовать его". Вариацией этой проблемы является общая библиотека компонентов, используемая в нескольких проектах и не поспевающая за их требованиями.
На официальной странице продукта на сайте KORG написано "The world's first* 3D display oscilloscope screen", а в новостях в медиа о его релизе - просто "3D oscilloscope", так что это именно что осциллограф в обычном словоупотреблении, а не осциллятор. Строго говоря, есть и в русском языке слово "осциллоскоп", подвидом осциллоскопов являются осциллографы, умеющие записывать колебания на бумаге (корень "-граф"), но все называют осциллоскопы осциллографами.
Если это воспринимать как метафору, т.е. "DDD - это как микросервисная архитектура, но для наших ментальных моделей, отражаемых в коде, а не для самого кода и его технологической обвязки", то это довольно удачная метафора, не описывает все DDD, но указывает на ключевые вещи. Но у вас в статье получилось слишком буквальное сравнение, что понятно - вы старались донести действительно удачную метафору. Все возражения как мне кажется по поводу этой буквальности. Но для начала обсуждения неплохо. Скажем вы пишете в ответе на другой коммент: "И не превратится ли это "много" в очередную монструозную систему на базе кубера?" - хороший вопрос! Но бывают действительно сложные предметные области, в которых тесно переплетены многие сущности. И ведь именно для таких областей наши информационные системы могут оказаться особенно полезны - если мы хоть немного помогли справиться со сложностью, то мы герои. И вот для таких сложных случаев и нужны, скажем, паттерны из "синей книги" - там ведь не только про то, что надо разделять и властвовать, но и про связи между компонентами - как добавлять эти связи так, чтобы не получилось "монструозного кубера". На ютубе есть выступление Эванса как раз про микросервисы и DDD кстати.
Вы просто не улавливаете определенных культурных особенностей, формально вы все правильно пишете, и более того, описанные вами в первой статье приемы работают, но не оптимальны, вы просто, извините, задолбаетесь так работать, выгорите еще до первого повышения xD Да, решать вопросы с привлечением руководителя - это "против лома нет приема", но это долго. Красный цвет действует, но когда в ваших сообщениях все к нему привыкнут и перестанут замечать, как вы будете дальше писать - красным жирным капсом? xD И так далее. Но с другой стороны, чем больше вы будете упорствовать в своей стратегии, тем быстрее набьете нужное число шишек, чтобы ее поменять, и поскольку вы джун, то для вас это естественно. И даже не странно для джуна писать статьи о том, чего он не понимает - для вас естественно не понимать, что вы не понимаете xD Но вот что мы это читаем и возмущенно комментируем - это поистине странно. Но так, видимо, работают медиа - чем дебильней и несущественней обсуждение, тем больше желания к нему присоединиться xD
Можете не читать Agile Manifesto, а прочесть только список его "подписантов" и подумать о том, много ли среди них "бизнеса". Аджайл придумали разработчики успешных проектов (а вовсе не бизнес), которым пришлось реализовывать массу новых фич, поток которых был обусловлен успехом проектов. Затем он был подхвачен "стартап-культурой", у которой были аналогичные запросы.
Скорее всего в том типе компании, которую описывает автор поста, после такой просьбы к руководителю вам предстоит еще общение с вашим руководителем на тему "а все ли у вас в порядке, а уверены ли вы, что без чрезмерного труда справляетесь с рабочими задачами" и потом, вероятно, также общение с сотрудником HR-отдела на ту же тему, возможно с "очной ставкой" с этим самым человеком, с которым вы отказались работать. Потому что конечно же для более-менее отлаженной организации отказываться с кем-либо работать не то чтобы ненормально, но вызывает большие напряжения у менеджмента, который начинает переживать, что не все отлажено. Причем ваш руководитель будет понимать, что за той же инфой аналитик придет к нему, если вы откажетесь с ним общаться, так что вашему руководителю будет гораздо удобнее наладить ваше взаимодействие с аналитиком.
Ответом по существу будет "отказать с объяснением, почему отказано", тогда и поход к руководителю, возможно, не нужен будет. Задача аналитика, который к вам пришел, - сделать так, чтобы вам выгоднее было выдать максимум информации, чтобы от вас отвязались. Ведь его работа - собирать и агрегировать инфу, и в особенности на ранних этапах профессионального развития ему важно с вас стрясти максимум информации, чтобы как нейросеть на ее объеме обучаться.
Руководитель, кстати, скорее встанет тут на сторону аналитика по той же причине, - ему проще выдать аналитику максимум инфы, чтобы не менеджерить общение с ним до бесконечности, и потом получить адекватные требования для подготовки задач в работу, потому что от аналитиков в первую очередь зависит качество требований.
Понятно, что любой адекватный человек не мечтает о том, чтобы другим было с ним неприятно общаться. Но в конечном-то итоге если вы таким образом избегаете ответа по существу, то к вам все равно потом придут, но с вашим руководителем. И именно зная это вы скорее всего и не отмахнетесь.
Ваши "гори в аду" как раз показывают, что это работает и вы будете неспособны это проигнорировать, особенно четвертый пункт, но ведь автор статьи дает советв не вам, а тому, кто с вами взаимодействует. В большой корпорации без некоторой доли работы локтями никак. И да, встреча с руководителем решает проблему с переадресацией.
Есть задачи, по которым все вами выше сказанное справедливо, а есть те, по которым сроки очевидны или даже приняты как обязательства. Если вы о задаче первого типа напишете то, что написали выше, то вполне "подскажете по срокам", вы дадите свою оценку неопределенности для задачи и покажете, каков текущий этап работы над ней.
Вопрос только в том, как быть, если "коллега" как раз и занят разработкой "готовых решений". Или они магическим образом решают все эти проблемы?
Какая-то агитка вместо статьи. Не разрабатываю для мобилок и не имею симпатий ни к нативным инструментам, ни к инструментам типа Flutter, но статья кажется пытается скорее рекламировать, чем информировать.
Я работал на удаленке сначала за 7 часовых поясов в одну сторону, потом 5 часовых поясов в другую, каждый раз основная часть команды была не в моем поясе, и как-то норм.
Пытаюсь представить кого-то из аудитории Хабра, кто испытывает настолько сильный гнев и единственный способ решения проблемы - регулярные пробежки. Какой-нибудь программист "системы взимания платы" Платон, ненавидящий коррумпированных боссов? Заказчик второсортного аутсорсера, пофейлившего все сроки? (Я работал на таком проекте, к моменту моего прихода все сроки были уже безнадежно пофейлены, причем заказчик был весьма и весьма престижной западной компанией и они продолжали с нами работать! Подозреваю, что возможно решали эмоциональные проблемы пробежками как раз, лол)
Если у вас дейли скрам занимает по полчаса, то вы вероятно не видели нормально работающую по скраму команду и попросту представляете, что такое скрам, скорее формально. Однако если бы команда и была работающая по скраму, я бы не называл прирост эффективности работы главной целью скрама - в реальности он нужен для предсказуемости результатов работы команд для менеджмента, т.е. для большей управляемости процесса разработки. Если в этой части вы не добились результатов - увольте или подайте в суд на тех, кто внедрял вам скрам.
Знающие люди советуют в таких случаях пользоваться паттерном State от GoF, вот здесь есть пример, который кажется похож на на вашу ситуацию, но без всякой логики в сервисах.
https://stackoverflow.com/a/10013528
Фендер от гибсона при сопоставимом пути сигнала можно отличить, хамбакеры от синглов все-таки отличаются значительно (предположим что под фендером понимается страт или телекастер, а под гибсоном - Les Paul и что на фендере при записи был включен хотя бы один сингл). В коргах и ямахах, если говорить скажем о 1980-х, использовались разные механизмы синтеза (скажем Ямаха стала сильно топить в FM в какой-то момент, а Корг с Роландом и прочими развивали PWM и phase distortion) и они конечно звучат по-разному. Вот это для аудиофила как раз интересно, отражает историю музыки в ее связи с историей технологий, показывает, как разные музыканты использовали возможности и ограничения доступных им технологий и т.п.
Не уверен, что русское слово "модуль" в переводе используется удачно, модули могут использоваться и без намерения создавать семейство продуктов. Во многих энтерпрайз-системах логирование или аналитика выделены в отдельный модуль, но не потому что всерьез предполагается его замена в случае изменившихся требований, а просто потому что его не хочется собирать и деплоить с каждым релизом.
Насчет "не переиспользовать код" вы невнимательно прочли, ключевое место там:
Это довольно часто встречающаяся ситуация, когда много разных сценариев использования проходят через один компонент, который сначала кажется весьма полезным (и является полезным в какой-то степени), но потом становится бутылочным горлышком с точки зрения поддержки. В этих случаях нужно просто отказаться от логики "у нас уже есть компонент с 90% нужного функционала, поэтому нужно обязательно использовать его". Вариацией этой проблемы является общая библиотека компонентов, используемая в нескольких проектах и не поспевающая за их требованиями.
Это НЛП какое-то, а не русский язык.
Наверно на русском языке это точней всего было бы назвать "3D-визуализацией сигнала", т.к. слово "осциллограф" у нас больше про физический прибор.
На официальной странице продукта на сайте KORG написано "The world's first* 3D display oscilloscope screen", а в новостях в медиа о его релизе - просто "3D oscilloscope", так что это именно что осциллограф в обычном словоупотреблении, а не осциллятор. Строго говоря, есть и в русском языке слово "осциллоскоп", подвидом осциллоскопов являются осциллографы, умеющие записывать колебания на бумаге (корень "-граф"), но все называют осциллоскопы осциллографами.