Бояться таких инженеров — значит бояться роста. Гораздо умнее — научиться работать рядом с ними: использовать их ум, вовлекать их в принятие решений, давать им пространство влиять. Потому что в конечном счёте успех продукта определяют не тишина на митингах и не отсутствие споров, а глубина решений, которые принимает команда.
Добрый день.
У меня ровно 2 крупных мысли возникло по прочитанному, поделюсь ими. Прошу не считать их критикой, а считать моим дополнением к вашей статье.
Мысль первая - а есть ли потребность в росте? Рост, мы растём, у нас быстрые темпы роста и т.д. - хорошие (наверное) маркетинговые слоганы. Но есть ли потребность в росте на самом деле? Рост основан с одной стороны на личных качествах владельца компании (именно владельца, а не руководства) который имеет задачи в росте компании из за личных амбиций (количество таких людей исчезающе мало) или из за объективных требований рынка, которым необходимо соответствовать для выживания. Понимание этого факта делает вопрос кто прав, кто не прав - более сложным для исследования (нужна полнота информации), но более простым для понимания - нет потребности быть сложнее чем это объективно необходимо бизнесу.
Мысль вторая - научится работать. Звучит правильно, только вопрос, сколько времени займет обучение, и кто за него заплатит. Вами описан процесс обучения, за которое платит описанный вами специалист, своей доп. нагрузкой, нервами. Обучаемый руководитель по факту может не обучатся вовсе, как говорится - где нет ученика, там нет и учителя. В свете сказанного можно допустить, что сотрудники занимающие пассивную позицию могут по факту обладать более глубоким пониманием ситуации в целом - хотя в большинстве случаев это конечно же не так.
Здраствуйте. Спасибо, что уделили время. Надеюсь статья вам понравилась, или хотя бы принесла пользу, любую.
Думал как ответить на вашу просьбу - писать проще. Надумал на целую книгу про Жизнь в коллективе людей, отношения в социальных группах, созависимость и авторитет, социальный статус как суррогат знаний...
Лучше я отвечу просто - это не я такой, это жизнь такая :)
Прошу не злится и понять. Желаю вам всего наилучшего!
Если совсем упростить, то статья про:
1) Как проектировать приложения не перегружая мозг 2) Для этого понимаем, что наше приложение при запуске будет состоять из одного или более объектов ОС - процесса 3) Давайте при проектировании приложения сразу спроектируем наши процессы - они всё равно будут, так лучше подумать о них заранее 4) Чтобы лучше понимать друг друга будем говорить - архитектура приложения или архитектура кода 5) Описываю, какие аспекты оказывают ключевое влияние при проектировании архитектуры приложения и архитектуры кода
Я бы сам с удовольствием таким пользовался, но пока что все очень зыбко, все делят пространство абстракций на свои блоки, границы которых не совпадают.
Думаю это общая проблема человеческого мышления, которое очень плохо воспринимает абстракции над абстакциями.
Смысл статьи - рассказать, что проектирование приложения, как набора процессов ОС и проектирование кода вещи разные, но сильно взаимосвязанные.
Во во, вам в секцию "свидетелей rich моделей" но заходите только предварительно надев каску, ребята там нервные :)
Шоколад может есть себя, чужим ртом, это нормально, если это не разрешить, то увеличивается риск создания God object :) В итоге, на вопрос, что делает этот класс, тебе отвечают - забей, это просто класс, смотри методы :)
Все игроки бизнеса сидят за столом, играют в гляделки - кто первый начнет готовить кадры, которые можно будет сманить другим или подобрать с рынка безработных, тот лох и проиграл. Никто не хочет проигрывать.
Это вы оптимистично смотрите на действительность. На самом деле всем по...й, зарплатка платится и хорошо, что будет завтра о том не думают, так как думание требует напряжения, а не иммитации такового. Кризис во всех отраслях, по всему миру именно по этой причине - потребление везде и во всём как идеология достигла своего аппогея, даже мысли хотят потреблять, а не производить. Как то так :)
Тут нечего путать. Сервис содержит НАБОР методов управляющих сущностью User, в вашем примере сервис имеет только один метод, что не отменяет его границы ответственности. Команда - отдельный метод, функция реализованная в виде объекта.
Для меня разница между этими двумя архитектурными сущностями очевидна, что я и попытался донести в 2-х статьях.
Самая большая ошибка которую я наблюдаю везде, это неверное восприятие целей других людей. Для многих будет огромным откровением, что должостные обязанности и корпоративная мотивация чаще всего совершенно не имеют ничего общего с истинной мотивацией служащих. В большинстве случаев единственной мотивацией служащих, и не только управленцев, является добыча средств к существованию. Защита своей кормовой базы является первейшей задачей любого вида живности на нашей планете - так как это по сути реализация первичного инстинкта, инстинкта выживания.
С автором полностью согласен, хотя автор не стал переходить границы дозволенного и указывать на наготу и уродство существующей системы смыслов и легенд про корпоративные культуры, вовлеченность и мотивацию персонала в цели компании, а также про отрицание всеми собственниками очевидного.
Собственники всеми силами отрицают свою роль "богатого Буратино" щедро вознаграждающего всех причастных к системе которая производит высокий, и виртуальный, социальный статус владельца - мой ИТ больше твоего ИТ, у нас процессные процессы и т.д.
Собственники отрицают, что большая компания это не следствие их больших амбиций, а следствие:
правил игры в капиталистической системе - становись больше иначе тебя сьедят, то есть опять просто выживание;
получение удовольствий от социальных ласк вследствие занятия высокой позиции в социальной иерархии группы.
Подписался на вас, буду ждать новых интересных статей.
Вам необходимо написать статью, как гипервизоры заменяют Kubernetes, думаю, что признательность мирового сообщества вам обеспечена. Нужно прекратить расходовать средства впустую, Kubernetes отправляется на свалку, сэкономленные ресурсы благодарное человечество тратит на более полезные вещи.
Конечно же иньекция зависимостей делается не радии иньекции, а ради повторного использования данных, состояния одной или нескольких зависимостей.
Если в вашем приложении нет хранимых состояний, вам не нужны объекты, достаточно будет голых функций, и конечно же ФП лучше подойдёт в этом случае.
Возможны компромисные варианты построения кода, когда объекты используются только там, где возникают хранимые состояния, остальной код реализуется делегатами. Преимуществами такого подхода является отсутствие избыточности, но недостатком является отсутствие гибкости. В бизнес-приложениях часто меняются требования, что может повлечь за собой серьёзные переработки в коде с заменой делегатов на объекты. В этом случае избыточная реализация с использованием Function Object выглядит предпочтительнее, так как поддержка изоляции состояний, данных присутствует изначально, так как все функции изначально являются объектами.
Наверное не стоит повторять, что не существует универсальных решений. Function Object также не является серебрянной пулей.
Да, я именно такого ответа и ожидал, так как это для меня пройденный этап.
По сути вместо определения уникальности типа через его имя, вы уникальный тип определяете через уникальное сочетание его параметров, для простых типов параметров вы используете обёртки record.
На мой взгляд добавление сущностей не остановлено их всё равно будет не меньше чем требуется для описания домента, но вводится дополнительная абстракция IAction<TQuery, TResult> которая не несёт никакой полезной нагрузки, она нужна чтобы реализовать уникальность типов через сочетание параметров.
При увеличении сложности проекта вы сами придёте к выводу, что этот подход недостаточно снижает сложность кода, будете искать более эффективный способ борьбы со сложностью.
Второе - как я понял вы не используете абстракции для моков, а добавляете, вынужденно, признак virtual ко всем public, internal методам класса именно только с целью возможности корректного написания тестов. Тут явная избыточность, и приглашение унаследоватся от класса и переопределить метод - проблем много, их не решить договорённостями, запретом не переопределять, не наследовать, особенно если команда большая.
Грабли торчат отовсюду. На них обязательно наступят.
Что такое сервис. Тем более обычный. Дайте определение, через совокупность его существенных признаков, которые отличают его от других понятий того же рода и позволяют однозначно идентифицировать.
Добрый день.
У меня ровно 2 крупных мысли возникло по прочитанному, поделюсь ими. Прошу не считать их критикой, а считать моим дополнением к вашей статье.
Мысль первая - а есть ли потребность в росте? Рост, мы растём, у нас быстрые темпы роста и т.д. - хорошие (наверное) маркетинговые слоганы. Но есть ли потребность в росте на самом деле? Рост основан с одной стороны на личных качествах владельца компании (именно владельца, а не руководства) который имеет задачи в росте компании из за личных амбиций (количество таких людей исчезающе мало) или из за объективных требований рынка, которым необходимо соответствовать для выживания. Понимание этого факта делает вопрос кто прав, кто не прав - более сложным для исследования (нужна полнота информации), но более простым для понимания - нет потребности быть сложнее чем это объективно необходимо бизнесу.
Мысль вторая - научится работать. Звучит правильно, только вопрос, сколько времени займет обучение, и кто за него заплатит. Вами описан процесс обучения, за которое платит описанный вами специалист, своей доп. нагрузкой, нервами. Обучаемый руководитель по факту может не обучатся вовсе, как говорится - где нет ученика, там нет и учителя. В свете сказанного можно допустить, что сотрудники занимающие пассивную позицию могут по факту обладать более глубоким пониманием ситуации в целом - хотя в большинстве случаев это конечно же не так.
Здраствуйте. Спасибо, что уделили время. Надеюсь статья вам понравилась, или хотя бы принесла пользу, любую.
Думал как ответить на вашу просьбу - писать проще. Надумал на целую книгу про Жизнь в коллективе людей, отношения в социальных группах, созависимость и авторитет, социальный статус как суррогат знаний...
Лучше я отвечу просто - это не я такой, это жизнь такая :)
Прошу не злится и понять. Желаю вам всего наилучшего!
Если совсем упростить, то статья про:
1) Как проектировать приложения не перегружая мозг
2) Для этого понимаем, что наше приложение при запуске будет состоять из одного или более объектов ОС - процесса
3) Давайте при проектировании приложения сразу спроектируем наши процессы - они всё равно будут, так лучше подумать о них заранее
4) Чтобы лучше понимать друг друга будем говорить - архитектура приложения или архитектура кода
5) Описываю, какие аспекты оказывают ключевое влияние при проектировании архитектуры приложения и архитектуры кода
Как то так
Я бы сам с удовольствием таким пользовался, но пока что все очень зыбко, все делят пространство абстракций на свои блоки, границы которых не совпадают.
Думаю это общая проблема человеческого мышления, которое очень плохо воспринимает абстракции над абстакциями.
Смысл статьи - рассказать, что проектирование приложения, как набора процессов ОС и проектирование кода вещи разные, но сильно взаимосвязанные.
Браво. Приятно встретить думающего человека, без -Ох Историй- шор про Атлантов расправивших плечи.
Во во, вам в секцию "свидетелей rich моделей" но заходите только предварительно надев каску, ребята там нервные :)
Шоколад может есть себя, чужим ртом, это нормально, если это не разрешить, то увеличивается риск создания God object :) В итоге, на вопрос, что делает этот класс, тебе отвечают - забей, это просто класс, смотри методы :)
Бизнесу всегда нужно ещё вчера и всё сразу, поэтому этим можно оправдать всё, вообще всё...
Напоминаю
Используй копипасту вместо выделения функций или классов, чтобы не терять времени на рефакторинг.
Пиши код без комментариев и осмысленных имён переменных, чтобы создать загадку для будущих читателей.
Соблюдай правило: "если работает — не трогай", даже если не понимаешь как.
Игнорируй требования к безопасности, производительности и тестированию, фокусируясь лишь на быстрой сдаче результата.
Не используй системы контроля версий и не делай бэкапов — пусть ощущение риска закаляет.
Ставь хаотичность и "быстроту" выше порядка и архитектурного планирования.
Это вы оптимистично смотрите на действительность. На самом деле всем по...й, зарплатка платится и хорошо, что будет завтра о том не думают, так как думание требует напряжения, а не иммитации такового. Кризис во всех отраслях, по всему миру именно по этой причине - потребление везде и во всём как идеология достигла своего аппогея, даже мысли хотят потреблять, а не производить. Как то так :)
Так это же хорошо, даже очень. Я не шучу, просто понимаю интересы людей которые там бюджетами заведуют.
Тут нечего путать. Сервис содержит НАБОР методов управляющих сущностью User, в вашем примере сервис имеет только один метод, что не отменяет его границы ответственности.
Команда - отдельный метод, функция реализованная в виде объекта.
Для меня разница между этими двумя архитектурными сущностями очевидна, что я и попытался донести в 2-х статьях.
Самая большая ошибка которую я наблюдаю везде, это неверное восприятие целей других людей. Для многих будет огромным откровением, что должостные обязанности и корпоративная мотивация чаще всего совершенно не имеют ничего общего с истинной мотивацией служащих. В большинстве случаев единственной мотивацией служащих, и не только управленцев, является добыча средств к существованию. Защита своей кормовой базы является первейшей задачей любого вида живности на нашей планете - так как это по сути реализация первичного инстинкта, инстинкта выживания.
С автором полностью согласен, хотя автор не стал переходить границы дозволенного и указывать на наготу и уродство существующей системы смыслов и легенд про корпоративные культуры, вовлеченность и мотивацию персонала в цели компании, а также про отрицание всеми собственниками очевидного.
Собственники всеми силами отрицают свою роль "богатого Буратино" щедро вознаграждающего всех причастных к системе которая производит высокий, и виртуальный, социальный статус владельца - мой ИТ больше твоего ИТ, у нас процессные процессы и т.д.
Собственники отрицают, что большая компания это не следствие их больших амбиций, а следствие:
правил игры в капиталистической системе - становись больше иначе тебя сьедят, то есть опять просто выживание;
получение удовольствий от социальных ласк вследствие занятия высокой позиции в социальной иерархии группы.
Подписался на вас, буду ждать новых интересных статей.
Заголовок статьи... Пожалуйста прочитайте.
Вам необходимо написать статью, как гипервизоры заменяют Kubernetes, думаю, что признательность мирового сообщества вам обеспечена. Нужно прекратить расходовать средства впустую, Kubernetes отправляется на свалку, сэкономленные ресурсы благодарное человечество тратит на более полезные вещи.
Хороший комплект, если медный радиатор действительно справится, то очень даже хороший.
Если бы ещё разьём M.2 был, так вообще огонь.
https://habr.com/ru/articles/954516/#comment_28943544
надеюсь, что этот комментарий снимет недопонимание
Конечно же иньекция зависимостей делается не радии иньекции, а ради повторного использования данных, состояния одной или нескольких зависимостей.
Если в вашем приложении нет хранимых состояний, вам не нужны объекты, достаточно будет голых функций, и конечно же ФП лучше подойдёт в этом случае.
Возможны компромисные варианты построения кода, когда объекты используются только там, где возникают хранимые состояния, остальной код реализуется делегатами. Преимуществами такого подхода является отсутствие избыточности, но недостатком является отсутствие гибкости. В бизнес-приложениях часто меняются требования, что может повлечь за собой серьёзные переработки в коде с заменой делегатов на объекты. В этом случае избыточная реализация с использованием Function Object выглядит предпочтительнее, так как поддержка изоляции состояний, данных присутствует изначально, так как все функции изначально являются объектами.
Наверное не стоит повторять, что не существует универсальных решений. Function Object также не является серебрянной пулей.
Да, я именно такого ответа и ожидал, так как это для меня пройденный этап.
По сути вместо определения уникальности типа через его имя, вы уникальный тип определяете через уникальное сочетание его параметров, для простых типов параметров вы используете обёртки record.
На мой взгляд добавление сущностей не остановлено их всё равно будет не меньше чем требуется для описания домента, но вводится дополнительная абстракция IAction<TQuery, TResult> которая не несёт никакой полезной нагрузки, она нужна чтобы реализовать уникальность типов через сочетание параметров.
При увеличении сложности проекта вы сами придёте к выводу, что этот подход недостаточно снижает сложность кода, будете искать более эффективный способ борьбы со сложностью.
Второе - как я понял вы не используете абстракции для моков, а добавляете, вынужденно, признак virtual ко всем public, internal методам класса именно только с целью возможности корректного написания тестов. Тут явная избыточность, и приглашение унаследоватся от класса и переопределить метод - проблем много, их не решить договорённостями, запретом не переопределять, не наследовать, особенно если команда большая.
Грабли торчат отовсюду. На них обязательно наступят.
У меня вопрос, как вы это будете регистрировать в ServiceProvider?
IAction<Guid, UserDto>Уточню, если у разных классов сигнатуры совпадают?
Тульский пряник, это не пряник, потому что уже есть мятный пряник.
ФП ? Кто то говорил о ФП?
Что такое сервис. Тем более обычный. Дайте определение, через совокупность его существенных признаков, которые отличают его от других понятий того же рода и позволяют однозначно идентифицировать.
ключевое слово "почти"?