Статья понравилась. Очень холиванпя тема, и очень "аргументированно" преподнесены тезисы.
Истинно хороший пункт в статье "Не нужно звать всех подряд" и про нет парой абзацев ниже.
Однако если вы используете эти 2 момента из статьи то остальное - нытьё :(
ИМХО Статья показывает как джун реагирует на объём информации. И как и почему не справляется. А комменты показывают, что плойка - предел интеллектуальной деятельности:). Я б, уволил человека, если он в нужном разговоре теряет контекст, и не приносит другой пользы...
Совещания перестают быть проблемой, если тебе нужно придумать как сделать задачу, уточнить требования и т. д. И при этом ты не просто "исполнитель на отвали". Ты сам начинаешь собирать совещания. Те самые на 5 минут :)
Письменная речь оставляет следы, но она очень очень медленная и она не даёт возможность "переспросить".
Устная речь быстрая, и позволяет понять проблему и быстро найти решение, если все участники достаточно интеллектуальны, конечно. Но не оставляет артефактов.
Выбирай тип речи в зависимости от обстоятельств.
К сожалению, очень много людей просто не способны держать темп разговора и вникать в суть проблемы. С автором статьи согласен, таких приглашать на встречи бессмысленно, вредно, они будут ныть. Но и поручать им работу, которая требует коммуникаций не стоит. Пущай копаются в болоте и делают простые задачи. Всегда нужны руки. А с руками разговаривать не нужно :) и слушать их тоже особо не стоит :).
Добавлю тут один принцип не менее холиварный: ты уточнил? - Я написал - А он? - Пока не ответил - Ну так позвони, а если не возьмёт трубку, звони его начальнику, но за час до звонка напиши, что бы формальность соблюсти.
И ещё один: Я в комменте к задаче написал. - Ты донёс мысль до исполнителя? Убедился что он понял? Нет? - Нет, но он должен был прочитать комментарий, там же написано - Нет не должен. Не должен человек читать 1000 комментариев, Если что-то реально важное, внеси в тело задачи и явно убедить, что его приняли и поняли. Если этого не сделал, ну значит ты ничего не сделал. На заборе тоже написано, а под забором ещё и навалено.
Верно в примере такси зависит от нашей потребности.
Рассмотрим второй вариант:
Мы говорим в интерфейсе, что нужно сделать перевозку.
Есть внешний агрегатор такси. Не зависящий от нас
Значит нужен слой внешнего взаимодействия, например секретарь или логист. У которого есть метод отвези мою посылку, который нужен нам, и он адаптирует его к одному или нескольким агрегаторам.
Для меня как для заказчика (юзкейса) абсолютно не важно какой размер груди у секретаря или какие мозоли у логиста. Главное что есть кому сказать отвези.
Из этого примера видно, что слой внешнего взаимодействия зависит от слоя юзкейсов и от внешнего АПИ одновременно.
Как я понял из статьи и собственного применения, читай что можно его (описание интерфейса) расположить в одном файлике/папке/неймспейсе (зависит от языка) с МВУ
А МНУ будет подключать/наследовать МВУ для получения описание интерфейса.
Тут не понятно что имеется ввиду? Каких случаях? И просьба задать вопрос без кода, так как код должен являться результатом применения модели / принципа, а не источником.
Код сверху не описывает зависимости, так что плохо применим к описанию проблемы.
Ответ на то что понимается под зависит и использует был дан выше.
Я увидел что Вам не понятна разница между использованием реализации [интерфейсов] и зависимостью, то есть неким аналогом наследования, использования кодовой базы непосредственно.
Это тема кажется не интересной к обсуждению так как относится или к смешению контекста или глубинному не пониманию абстракций.
Читай включает, наследует использует кодовую базу непосредственно. Не путать с использует реализацию, которое как раз отвечает за понятие использует в рамках модулей бизнес логики и обычного языка.
Юзкейс может использовать реализации из (читай использует) внешнего взаимодействия
Upd Модель основана на чистой архитектуре. Если она Вам не знакома, то увы объяснение терминов может свестись к некому описанию чистой архитектуры. Что не очень продуктивно.
Я использую легковое такси. Как способ доставки моего товара от подъезда до подъезда.
Я не завишу от марки и модели автомобиля который перевезёт мой товар. Не завишу ни от чего внутри автомобиля.
Я определил интерфейс - перевезти. И его использую.
Но от его реализации я не завишу.
upd Как дополнение. В момент перевозки я использую конкретный экземпляр такси. Который предоставлен мне конкретным провайдером. Которого я могу сменить без влияния на результат.
Тут есть зависит. В в данном случае зависит (имеет зависимость) близко по смыслу к включает, наследует использует кодовую базу непосредственно. Не путать с использует реализацию.
На примере юзекйса и внешнего взаимодействия (конкретных):
Внешнее взаимодействие зависит от юзкейса.
Юзкейс может использовать реализации из внешнего взаимодействия
Статья понравилась. Очень холиванпя тема, и очень "аргументированно" преподнесены тезисы.
Истинно хороший пункт в статье "Не нужно звать всех подряд" и про нет парой абзацев ниже.
Однако если вы используете эти 2 момента из статьи то остальное - нытьё :(
ИМХО Статья показывает как джун реагирует на объём информации. И как и почему не справляется. А комменты показывают, что плойка - предел интеллектуальной деятельности:). Я б, уволил человека, если он в нужном разговоре теряет контекст, и не приносит другой пользы...
Совещания перестают быть проблемой, если тебе нужно придумать как сделать задачу, уточнить требования и т. д. И при этом ты не просто "исполнитель на отвали". Ты сам начинаешь собирать совещания. Те самые на 5 минут :)
Письменная речь оставляет следы, но она очень очень медленная и она не даёт возможность "переспросить".
Устная речь быстрая, и позволяет понять проблему и быстро найти решение, если все участники достаточно интеллектуальны, конечно. Но не оставляет артефактов.
Выбирай тип речи в зависимости от обстоятельств.
К сожалению, очень много людей просто не способны держать темп разговора и вникать в суть проблемы. С автором статьи согласен, таких приглашать на встречи бессмысленно, вредно, они будут ныть. Но и поручать им работу, которая требует коммуникаций не стоит. Пущай копаются в болоте и делают простые задачи. Всегда нужны руки. А с руками разговаривать не нужно :) и слушать их тоже особо не стоит :).
Добавлю тут один принцип не менее холиварный: ты уточнил? - Я написал - А он? - Пока не ответил - Ну так позвони, а если не возьмёт трубку, звони его начальнику, но за час до звонка напиши, что бы формальность соблюсти.
И ещё один: Я в комменте к задаче написал. - Ты донёс мысль до исполнителя? Убедился что он понял? Нет? - Нет, но он должен был прочитать комментарий, там же написано - Нет не должен. Не должен человек читать 1000 комментариев, Если что-то реально важное, внеси в тело задачи и явно убедить, что его приняли и поняли. Если этого не сделал, ну значит ты ничего не сделал. На заборе тоже написано, а под забором ещё и навалено.
Спасибо за статью :)
И мне, если не сложно
Верно в примере такси зависит от нашей потребности.
Рассмотрим второй вариант:
Мы говорим в интерфейсе, что нужно сделать перевозку.
Есть внешний агрегатор такси. Не зависящий от нас
Значит нужен слой внешнего взаимодействия, например секретарь или логист. У которого есть метод отвези мою посылку, который нужен нам, и он адаптирует его к одному или нескольким агрегаторам.
Для меня как для заказчика (юзкейса) абсолютно не важно какой размер груди у секретаря или какие мозоли у логиста. Главное что есть кому сказать отвези.
Из этого примера видно, что слой внешнего взаимодействия зависит от слоя юзкейсов и от внешнего АПИ одновременно.
Как я понял из статьи и собственного применения, читай что можно его (описание интерфейса) расположить в одном файлике/папке/неймспейсе (зависит от языка) с МВУ
А МНУ будет подключать/наследовать МВУ для получения описание интерфейса.
Тут не понятно что имеется ввиду? Каких случаях? И просьба задать вопрос без кода, так как код должен являться результатом применения модели / принципа, а не источником.
Код сверху не описывает зависимости, так что плохо применим к описанию проблемы.
Ответ на то что понимается под зависит и использует был дан выше.
Нет не идентично.
Ибо суть понята не до конца верно.
Реализация интерфейса может быть любой (использует), а вот объект из энтити только строгого состава зависит.
Я увидел что Вам не понятна разница между использованием реализации [интерфейсов] и зависимостью, то есть неким аналогом наследования, использования кодовой базы непосредственно.
Это тема кажется не интересной к обсуждению так как относится или к смешению контекста или глубинному не пониманию абстракций.
Прошу прощения если задел.
Читай комментарии сверху они дают различие в терминологии.
Но на всякий случай использовать в рамках статьи имеется ввиду результат деятельности.
Но бывает слово используется (причем другое) для описания использования кодовой базы что является зависимостью в терминологии статьи и комментариев :)
Нет usecase зависит от entity и использует реализации из внешнего взаимодействия.
Я прям над вашим комментарием написал разницу между зависит и использует.
Нет он от него зависит
Usecase зависит от entity.
Читай включает, наследует использует кодовую базу непосредственно. Не путать с использует реализацию, которое как раз отвечает за понятие использует в рамках модулей бизнес логики и обычного языка.
Юзкейс может использовать реализации из (читай использует) внешнего взаимодействия
Upd Модель основана на чистой архитектуре. Если она Вам не знакома, то увы объяснение терминов может свестись к некому описанию чистой архитектуры. Что не очень продуктивно.
Я использую легковое такси. Как способ доставки моего товара от подъезда до подъезда.
Я не завишу от марки и модели автомобиля который перевезёт мой товар. Не завишу ни от чего внутри автомобиля.
Я определил интерфейс - перевезти. И его использую.
Но от его реализации я не завишу.
upd Как дополнение. В момент перевозки я использую конкретный экземпляр такси. Который предоставлен мне конкретным провайдером. Которого я могу сменить без влияния на результат.
Тут есть зависит. В в данном случае зависит (имеет зависимость) близко по смыслу к включает, наследует использует кодовую базу непосредственно. Не путать с использует реализацию.
На примере юзекйса и внешнего взаимодействия (конкретных):
Внешнее взаимодействие зависит от юзкейса.
Юзкейс может использовать реализации из внешнего взаимодействия
В теле сатьи есть определения МВУ и МНУ. Они чётко дают понимание терминов выше и ниже.
Кажется мы разговариваем о разном. Я предлагаю ещё раз вернуться к определениям и понять в них есть слово использует но нет слова зависит.
А вот зависимость кодовой базы - это уже применение принципов скрываемых за идеей, например за SOLID.
Что такое формально определить?
Что хочется услышать на это? Есть ли непротиворечивый пример?
Суть вопроса не понятна.
Ибо выше и ниже чётко определяется в статье.
Использует - это базовое слово.
пользоваться -зуюсь, -зуешься; несов. 1. (несов. воспользоваться) чем. Прибегать к чему-л., обращаться к чему-л. для своих нужд и потребностей.
Юзкейс использует реализацию интерфейса и в конечном счёте хранилище, если реализация его использует.
Тут появляется очень много имхо ненужной конкретики: инфраструктура, геттеры, конструктор. Они имхо к сути не имеют никакого отношения.
Не понимаю сути вопроса.
Тут хорошее определение: использует, а не зависит.
"""При этом у многих людей в разговорной лексике "верхнее" потому и "верхнее", что зависит от "нижнего"."""
Непонятно ни про многих ни про зависимость. Кажется ровно наоборот.