то как бы не получается, что компрессор с частотным управлением экономичнее старт-стопного. Никак, почему-то, не получается.
У старт-стопного есть гистерзис, у инверторного нет. И верхний край этого гистерзиса как раз и устанавливается на уровне заданной температуры. То есть, если холодильник установлен на 2 градуса, то он начинает молотить при двух. А при одном выключается. То есть он тупо делает температуру ниже, чем надо. А ещё тепловая инерция. Переморозить сильнее, чем надо как нефиг делать.
Инверторник тупо ПИДит сколько энергии надо вкидывать в поддержание температуры и не тратит лишнего.
Я вот так и не научился писать код без багов. Хотя я не вкатун. И в срок это не про меня, особенно если срок спускают сверху. Ну хоть вроде без паники.
приходит в первый день на проект, открывает Jira — и не понимает ничего.
Помню свои ощущения после выхода на новую работу. Именно так. Не понимаю ничего. И на второй день не понимаю. И на третий. И так на каждой работе. Так я всё-таки вкатун?
ощущение, что ты всех обманул и вот-вот это вскроется
Тоже было.
У меня ощущение, что текущая ситуация всех устраивает. Ну всмысле компании довольны, что они набирают "опытных" разрабов, а их "синьёры" их развивают. "Опытные" разрабы тоже довольны, что вкатились. "Синьёры" тоже довольны, что их синьёрят. А хрен знает, кто недоволен.
А-а-а-а, по существу... Да не знаю. Наверное хорошие инструменты для работы. Не обязательно один универсальный, можно под каждую область свой, но хороший.
Не уйдём мы от множества форматов, не уйдём. Универсальность инструмента приводит к всратости формата.
— Если я ошибся, скажи сразу. А не заставляй делать всё заново.
И как я скажу, что пользователь ошибся? Как я пойму?
Особенно это критично на мобильных устройствах, где вероятность ошибки выше
Так может не так уж и бессмысленно? Пользователь дважды вводит пароль и вероятность, что он ошибся дважды на несколько порядков ниже, чем вероятность ошибиться один раз.
Ну так берите и сделайте. Я же не обещал вам. В чём проблема? За вас кто-то работу будет делать бесплатно и бесплатно вас учить? Может быть, но это не я.
Не хочу. Вы кажется проигнорировали, где я объяснял, почему.
Давайте ещё одно объяснение дам. Мне вообще нахер не впилось себе конкуренцию создавать. Ну не работает DDD и ладно, я соглашусь. Оно мне надо что-то вам доказывать?
Чтобы в вашем проекте мне сделать DDD, мне нужно досконально разобраться с вашей же предметной областью. Вопрос. Мне за потраченное время кто-нибудь заплатит?
Так вы и сейчас можете представить. Просто если пихать DDD в простой сервис, где он не нужен - вы ничего не увидите. А вот когда у вас сложная предметная область, и когда быстро меняется логика взаимодействия между объектами предметной области, тогда DDD хорош. Там нет ничего космического. Ничего, что бы противоречило здравому смыслу.
Просто я не возьмусь бесплатно ваш проект выправлять, а сумма вам не понравится. А просто чтобы показать, чем DDD хорош - ну у меня мотивации нет.
Я даже знаю, где их применение удачно. В каком-нибудь суперуспешном и супернагруженном проекте. Там где много разрабов, много денег, отлажены процессы и очень много rps. Миллионы. Но при этом от сервисов не требуется рокет саенс. Один микросервис котиков отдаёт, второй сиськи. А мы их масштабируем в зависимости от нагрузки. Ну я так, очень утрировано.
А, знаю этот прикол. Когда делают микросервисы часто упираются в связность взаимодействия. Получается как-бы монолит по связности, но на обслуживание сериализации/десериализации уходит 60% cpu. И плюшки вроде падения в рантайме из-за рассинхрона апишечки.
Про ваш монолит. Поверьте, несколько дней от аппрува до мастера - это ещё очень лайтово. Учитывая количество разрабов кодобазы. Когда количество разрабов растёт, ломаются нахер все ранее работавшие процессы. Лиды не успевают всех ревьюить. Пуш гита прокатывает с 3й или 4й попытки мержа. Репозиторишна опухла или как. У нас была поменьше репа (наверное) в 34гб, но был hg, потому что гиту было с ней ой как плохо.
Ну тут реально пилить надо, Шура. Причём скорее не на сервисы, а на команды, тут больше административных проблем. И решать их сложно. Микросервисы даже тут очень плохая идея. Микросервисы просто перенесут сложность взаимодействия на этап интеграции, по факту ничего не решив и только добавив своей "специфики".
Ну как монолит, только распределённый. Когда пишется большая система, обычно делается монолит, это просто следствие yagni.
Потом, когда (и если) возникает необходимость масштабировать (упирается в rps/cpu/mem), то возникает идея распределить нагрузки на несколько узлов. Самый простой вариант - отделить ту часть, которую можно распараллелить. Тут даже можно запускать один и тот же разный монолит, но с разными ключами, назначив мастер-ноду. Много разных способов существует. Может быть даже каждый монолит со своей БД, завёрнутый в докер. Может они равноправны и ходят в одну БД. Это всё зависит от типа приложения и характера нагрузки, потому что распараллеливание нужно для оптимизации нагрузки.
Да, именно так. Большие проекты сами подталкивают к этому. Но нужен опыт, чтобы смотреть на это не как на статичный код, а как на процесс собственно разработки.
Отделение быстромутирующего кода от фундаментального - это один из принципов. Да, со временем он сам по себе появится. Следование единой терминологии с предметной областью тоже само появляется, когда хочется не запутаться в большом проекте.
Целые книги не знаю, зачем появляются. Я вот сам дошёл до DDD. Может быть это написано для тех, кто не хочет годами сам доходить до этих мыслей. Для тех, кто хочет срезать углы и сразу подготовиться к большим проектам, не наделав на старте ошибок.
Кстати, "документ" - это плохое название для сущности. Это могут быть счета, накладные, акты, договоры или приложения к ним. Да много чего. У каждого документа - своё прикладное значение. И чаще всего он появляется не сам по себе, а как фиксирующая какую-либо информацию сущность у другой сущности, уже из предметной области.
Так смысл перераспределения именно в этом. Базовый закон сложности - это когда сложность одной задачи умножается на сложность другой. При N задачах это всё вырождается в O^N сложность, то есть невозможную.
Смысл управления сложностью как раз в том, чтобы по максимуму оградить каждую задачу от сложностей другой. То есть приблизиться к линейной. К O = (N).
С самой сложностью бороться бесполезно, но её можно сократить до известных пределов.
У старт-стопного есть гистерзис, у инверторного нет. И верхний край этого гистерзиса как раз и устанавливается на уровне заданной температуры. То есть, если холодильник установлен на 2 градуса, то он начинает молотить при двух. А при одном выключается. То есть он тупо делает температуру ниже, чем надо. А ещё тепловая инерция. Переморозить сильнее, чем надо как нефиг делать.
Инверторник тупо ПИДит сколько энергии надо вкидывать в поддержание температуры и не тратит лишнего.
Я вот так и не научился писать код без багов. Хотя я не вкатун. И в срок это не про меня, особенно если срок спускают сверху. Ну хоть вроде без паники.
Помню свои ощущения после выхода на новую работу. Именно так. Не понимаю ничего. И на второй день не понимаю. И на третий. И так на каждой работе. Так я всё-таки вкатун?
Тоже было.
У меня ощущение, что текущая ситуация всех устраивает. Ну всмысле компании довольны, что они набирают "опытных" разрабов, а их "синьёры" их развивают. "Опытные" разрабы тоже довольны, что вкатились. "Синьёры" тоже довольны, что их синьёрят. А хрен знает, кто недоволен.
Денег, счастья, здоровья.
А-а-а-а, по существу... Да не знаю. Наверное хорошие инструменты для работы. Не обязательно один универсальный, можно под каждую область свой, но хороший.
Не уйдём мы от множества форматов, не уйдём. Универсальность инструмента приводит к всратости формата.
Да вы знаете, что тут комикс xkcd
И как я скажу, что пользователь ошибся? Как я пойму?
Так может не так уж и бессмысленно? Пользователь дважды вводит пароль и вероятность, что он ошибся дважды на несколько порядков ниже, чем вероятность ошибиться один раз.
Ну и отлично. На этом и разойдёмся. Меня всё устраивает.
Ну так берите и сделайте. Я же не обещал вам. В чём проблема? За вас кто-то работу будет делать бесплатно и бесплатно вас учить? Может быть, но это не я.
Не говорит. Вас прямо спросили, как вы ООП от DDD отличать будете со своими критериями.
Дорогой Майкл. Не надо брать случайных пользователей интернета на слабо.
Одно дело, когда рассказываешь свой опыт и свою точку зрения, другое дело идти и делать работу. Которой у каждого хватает.
Кстати, если не заметили, статью писал не я.
Не хочу. Вы кажется проигнорировали, где я объяснял, почему.
Давайте ещё одно объяснение дам. Мне вообще нахер не впилось себе конкуренцию создавать. Ну не работает DDD и ладно, я соглашусь. Оно мне надо что-то вам доказывать?
Чтобы в вашем проекте мне сделать DDD, мне нужно досконально разобраться с вашей же предметной областью. Вопрос. Мне за потраченное время кто-нибудь заплатит?
Так вы и сейчас можете представить. Просто если пихать DDD в простой сервис, где он не нужен - вы ничего не увидите. А вот когда у вас сложная предметная область, и когда быстро меняется логика взаимодействия между объектами предметной области, тогда DDD хорош. Там нет ничего космического. Ничего, что бы противоречило здравому смыслу.
Просто я не возьмусь бесплатно ваш проект выправлять, а сумма вам не понравится. А просто чтобы показать, чем DDD хорош - ну у меня мотивации нет.
Вам не говорят, что это взаимоисключающие параграфы. Вам говорят, что логика в сущностях это не маркер DDD, а используется в простом советском ООП.
Я даже знаю, где их применение удачно. В каком-нибудь суперуспешном и супернагруженном проекте. Там где много разрабов, много денег, отлажены процессы и очень много rps. Миллионы. Но при этом от сервисов не требуется рокет саенс. Один микросервис котиков отдаёт, второй сиськи. А мы их масштабируем в зависимости от нагрузки. Ну я так, очень утрировано.
А, знаю этот прикол. Когда делают микросервисы часто упираются в связность взаимодействия. Получается как-бы монолит по связности, но на обслуживание сериализации/десериализации уходит 60% cpu. И плюшки вроде падения в рантайме из-за рассинхрона апишечки.
Про ваш монолит. Поверьте, несколько дней от аппрува до мастера - это ещё очень лайтово. Учитывая количество разрабов кодобазы. Когда количество разрабов растёт, ломаются нахер все ранее работавшие процессы. Лиды не успевают всех ревьюить. Пуш гита прокатывает с 3й или 4й попытки мержа. Репозиторишна опухла или как. У нас была поменьше репа (наверное) в 34гб, но был hg, потому что гиту было с ней ой как плохо.
Ну тут реально пилить надо, Шура. Причём скорее не на сервисы, а на команды, тут больше административных проблем. И решать их сложно. Микросервисы даже тут очень плохая идея. Микросервисы просто перенесут сложность взаимодействия на этап интеграции, по факту ничего не решив и только добавив своей "специфики".
Ну как монолит, только распределённый. Когда пишется большая система, обычно делается монолит, это просто следствие yagni.
Потом, когда (и если) возникает необходимость масштабировать (упирается в rps/cpu/mem), то возникает идея распределить нагрузки на несколько узлов. Самый простой вариант - отделить ту часть, которую можно распараллелить. Тут даже можно запускать один и тот же разный монолит, но с разными ключами, назначив мастер-ноду. Много разных способов существует. Может быть даже каждый монолит со своей БД, завёрнутый в докер. Может они равноправны и ходят в одну БД. Это всё зависит от типа приложения и характера нагрузки, потому что распараллеливание нужно для оптимизации нагрузки.
Мало. DDD начинает работать так навскидку от 10 тысяч строк. Да, для работы любого инструмента по управлению сложностью нужна эта самая сложность.
Да, именно так. Большие проекты сами подталкивают к этому. Но нужен опыт, чтобы смотреть на это не как на статичный код, а как на процесс собственно разработки.
Отделение быстромутирующего кода от фундаментального - это один из принципов. Да, со временем он сам по себе появится. Следование единой терминологии с предметной областью тоже само появляется, когда хочется не запутаться в большом проекте.
Целые книги не знаю, зачем появляются. Я вот сам дошёл до DDD. Может быть это написано для тех, кто не хочет годами сам доходить до этих мыслей. Для тех, кто хочет срезать углы и сразу подготовиться к большим проектам, не наделав на старте ошибок.
Кстати, "документ" - это плохое название для сущности. Это могут быть счета, накладные, акты, договоры или приложения к ним. Да много чего. У каждого документа - своё прикладное значение. И чаще всего он появляется не сам по себе, а как фиксирующая какую-либо информацию сущность у другой сущности, уже из предметной области.
Так смысл перераспределения именно в этом. Базовый закон сложности - это когда сложность одной задачи умножается на сложность другой. При N задачах это всё вырождается в O^N сложность, то есть невозможную.
Смысл управления сложностью как раз в том, чтобы по максимуму оградить каждую задачу от сложностей другой. То есть приблизиться к линейной. К O = (N).
С самой сложностью бороться бесполезно, но её можно сократить до известных пределов.
Если вы говорите, что разработка - это сидение попой на стуле, ты вы - [CENSORED].
Всего хорошего.
А, вы Джеки Чана снимаете? Снимаю шляпу, молодцы!
Лида тоже может и не быть. Ну вот вообще. И никто не понимает, что с этим кодом делать. Ну вот физически нет.
Лид ушёл. Что вы будете делать?