Я вашу стадию уже проходил)) У нас была модульная архитектура еще тогда, когда nwidart\internachi\им подобных пакетов и в помине не было) Это сейчас она пилится проще простого, а в те времена нам приходилось точечно оверрайдить логику лары :) Так что да, будем надеяться, что и у вас понимание придет :)
В целом не люблю использовать аналогии, но тут подходит - для хорошего UX стараются минимизировать количество переходов\кликов пользователя до получения нужного ему результата. Вот если представить, что вам для действия, которое на других сайтах занимает 2 клика, потребуется сделать 6 - как может когнитивная нагрузка быть меньше?
Представьте, что вы знаете эту архитектуру, но видите проект впервые. Чтобы понять, как конкретно работает хелсчек роут, вам придется "загрузить" в голову логику из 6 отдельных классов и построить представление работы этого кода. Не представляю, как это может оказывать меньшую когнитивную нагрузку, чем если бы, по вашему говоря, человек "заговнокодил" всю логику в 10-15 строк в контроллере. В этом кейсе человек, незнакомый с проектом\кодом, получит всю нужную ему информацию за 2 перехода - поиск нужного роута и переход в экшн контроллера. Офк, хелсчек это просто пример) Основная проблема здесь в том что, вероятнее всего, на своих проектах вы будете, в том числе с помощью инструментов CI, форсить "чистую архитектуру" и code coverage, тем самым снижая гибкость разработки
Респект за материал и подачу - сразу видно вложенные усилия, потраченные на пост. Особенно приятно, что есть референсы в виде ссылок.
Фидбек по сути\смыслу - если бы я знал, что меня ждет проект с таким подходом - я бы туда точно не пошел. Когнитивная нагрузка дикая (код чаще читают, чем пишут). Оверинжиниринг на лицо (потому что декларируется "уникально правильный" подход под все кейсы, а не гибкая разработка под ситуацию). Складывается ощущение, что для вас цель написания кода - это не решение проблем и ведение бизнеса, а маниакальное стремление к субъективному перфекционизму. Пока вы разрабатываете продукт, конкуренты уже захватят рынок и вам не останется на нем места. Bounded context, разделение слоев и зон ответственности в коде - это важно. Но это важно только для поддержки и расширения. Если у вас есть гарантия, что код будет одноразовый и ни для чего другого использоваться не будет - вы все равно будете разбивать функции вроде хелсчека на 6 классов или все же нужно решать в зависимости от контекста?
Такой вопрос: а в чем преимущество этого метода перед гит-хуками? Кажется, что можно аналогичное реализовать на них, чтобы работало вне зависимости от выбранной IDE?
Интересно, но, на первый взгляд, не особо эффективно - за счет большого количества параметров тяжело выделять конкретный фокус модели (подбирать нужный вес). Например, стоит задача повысить оборачиваемость - при таком подходе "подкручивать" модель под нужный фокус не просто больно, а физически тяжело - ведь, если я правильно понял, метрик довольно много и в итоге надо не просто подкрутить вес факторам, которые влияют на оборачиваемость, но и понять, какие из них и с какой силой на неё влияют)
Имхо, проще и легче было бы держать несколько режимов работы автоназначения, каждый из которых заточен на конкретный фокус, чем пытаться стремиться к "обобщенному идеалу" - потому что судя по описанию, складывается ощущение адового High Coupling'а :) Кто-то забыл про KISS?)
Супер релиз! Давно ждал фикса quality tools из «Важных исправлений»
Такой вопрос: а будет ли возможность записывать сессии code with me? Просто если да, то по по первому впечатлению будет отличный инструмент для проведения собеседований в удобном кандидату редакторе
Я вашу стадию уже проходил)) У нас была модульная архитектура еще тогда, когда nwidart\internachi\им подобных пакетов и в помине не было) Это сейчас она пилится проще простого, а в те времена нам приходилось точечно оверрайдить логику лары :) Так что да, будем надеяться, что и у вас понимание придет :)
В целом не люблю использовать аналогии, но тут подходит - для хорошего UX стараются минимизировать количество переходов\кликов пользователя до получения нужного ему результата. Вот если представить, что вам для действия, которое на других сайтах занимает 2 клика, потребуется сделать 6 - как может когнитивная нагрузка быть меньше?
Представьте, что вы знаете эту архитектуру, но видите проект впервые. Чтобы понять, как конкретно работает хелсчек роут, вам придется "загрузить" в голову логику из 6 отдельных классов и построить представление работы этого кода. Не представляю, как это может оказывать меньшую когнитивную нагрузку, чем если бы, по вашему говоря, человек "заговнокодил" всю логику в 10-15 строк в контроллере. В этом кейсе человек, незнакомый с проектом\кодом, получит всю нужную ему информацию за 2 перехода - поиск нужного роута и переход в экшн контроллера. Офк, хелсчек это просто пример) Основная проблема здесь в том что, вероятнее всего, на своих проектах вы будете, в том числе с помощью инструментов CI, форсить "чистую архитектуру" и code coverage, тем самым снижая гибкость разработки
Респект за материал и подачу - сразу видно вложенные усилия, потраченные на пост. Особенно приятно, что есть референсы в виде ссылок.
Фидбек по сути\смыслу - если бы я знал, что меня ждет проект с таким подходом - я бы туда точно не пошел. Когнитивная нагрузка дикая (код чаще читают, чем пишут).
Оверинжиниринг на лицо (потому что декларируется "уникально правильный" подход под все кейсы, а не гибкая разработка под ситуацию). Складывается ощущение, что для вас цель написания кода - это не решение проблем и ведение бизнеса, а маниакальное стремление к субъективному перфекционизму. Пока вы разрабатываете продукт, конкуренты уже захватят рынок и вам не останется на нем места.
Bounded context, разделение слоев и зон ответственности в коде - это важно. Но это важно только для поддержки и расширения. Если у вас есть гарантия, что код будет одноразовый и ни для чего другого использоваться не будет - вы все равно будете разбивать функции вроде хелсчека на 6 классов или все же нужно решать в зависимости от контекста?
Такой вопрос: а в чем преимущество этого метода перед гит-хуками? Кажется, что можно аналогичное реализовать на них, чтобы работало вне зависимости от выбранной IDE?
А в чем проблема? Пусть себе сидят, вам же лучше) Причём вне зависимости от того, за кого вы играете)
Лол, комменту полгода уже, ток сейчас прошел одобрение :D
Интересно, но, на первый взгляд, не особо эффективно - за счет большого количества параметров тяжело выделять конкретный фокус модели (подбирать нужный вес).
Например, стоит задача повысить оборачиваемость - при таком подходе "подкручивать" модель под нужный фокус не просто больно, а физически тяжело - ведь, если я правильно понял, метрик довольно много и в итоге надо не просто подкрутить вес факторам, которые влияют на оборачиваемость, но и понять, какие из них и с какой силой на неё влияют)
Имхо, проще и легче было бы держать несколько режимов работы автоназначения, каждый из которых заточен на конкретный фокус, чем пытаться стремиться к "обобщенному идеалу" - потому что судя по описанию, складывается ощущение адового High Coupling'а :)
Кто-то забыл про KISS?)
Такой вопрос: а будет ли возможность записывать сессии code with me? Просто если да, то по по первому впечатлению будет отличный инструмент для проведения собеседований в удобном кандидату редакторе