Когда читал про типы мышления, провел аналогию с собой — что-то в этом есть…
А про блуждающий разум: думаю, каждый разработчик сталкивался с ситуацией, когда решение идеи приходит в душе или на улице, когда думаешь совершенно о другом :)
Может Вы и правы, обычно сеньоры знают азы какого-нибудь React, Angular или Blazor (для С#), например. Для Java, если знаешь только Java, есть Vaadin — тоже неплохая штука. Что-то красивое серверные разработчики может и не сделают, но простую формочку нарисовать точно смогут.
“Если сеньор — серверный программист, то он понимает и различает JS-фреймворки.” — не все Middle Frontend (даже несмотря на разницу в градациях) умеют работать на нескольких фреймворках, а, оказывается, даже серверные сеньоры знают хотя бы несколько фронтент фреймворков :)
Спасибо за комментарий!
В ближайшие недели хочу разобраться во всех подходах, которые мне посоветовали\дополнили и дополнить свою архитектуру (на очереди — MobX).
Обязательно посмотрю Ваш репозиторий, не удаляйте его в ближайшее время, пожалуйста :)
«Вы перестарались, и цена фичи выросла раза в 4. Даже в Redux меньше „капусты“ и копипасты» — опять же, пример надуманный и здесь действительно много overengeneering'a.
«Высокий уровень входа для новичков (в меру высокий)» — не согласен. Вопрос изучения — максимум пару дней + поправка на общий опыт. В сравнении с тем, что пишут вообще без какого-либо подхода — я считаю, что архитектура выше большой шаг вперед. Собственно, и статью я написал потому, что не увидел других общепринятых подходов. Или только с акцентом на библиотеку, или вообще никак.
«Слишком много ручной работы, а следовательно высокая цена кода и большое пространство для формирования багов» — это тема для второй статьи. Собственно, во второй статье будет добавлен MobX и часть ручной работы отпадет.
Ключевая идея статьи в том, что серебряной пули нет — но есть такая, как описаны выше. И свои задачи она решает может не всегда идеально, но решает и в большинстве своем закрывает свои задачи.
Если у Вас будет время, можете рассказать, как бы Вы изменили архитектуру выше? Может просто созвониться и обсудить\пообщаться в Telegram. Я несомненно ищу пути улучшения подхода, который использую и статья — один из способов его улучшить в какой-то мере
Увидел Ваши пулл реквесты, спасибо за них. Просмотрел код и, если в слой presentation добавить MobX — действительно, код становиться понятнее (но, опять же, плюс The Clean Architecture — MobX можно положить только в один слой :), не трогая остальные. В Entities я его добавлять бы не стал)
На след. выходных я обязательно в нем разберусь. Спасибо, что потратили время и показали свое видение
P.S. Но отдельный момент — мой вариант, разумеется, не идеальный. Но он работает и понятен другим разработчикам, есть консистентность в проекте. Подходов много и мой — лишь один из них. Стремиться к идеальному, конечно, нужно, но идеальное — враг хорошего.
И Ваш код с MobX, как по мне, очень даже сильно дополнит архитектуру.
«Создается огромное количество абстракций которые создаются не потому, что они нужны и улучшают читаемость, а потому, что так требует архитектура.» — да, проект надуманный. Но, опять же, чем больше появляется логики — тем большее ее смысл.
«Я больших проектах я рекомендую Атомарный дизайн» — можете продублировать ссылку? К сожалению, не открывается
«Я переписал это приложение, сделав ближе к тому, что я считаю чистой архитектурой» — на след. выходных я выделю время, чтобы разобраться, интересный подход
«А в чём собственно сложность тестирования?» — я имел ввиду не только передачу состояния, а тестирования для проекта в целом (включая передачу данных, обработку данных, изменение View в зависимости от изменения данных и т.д.).
«И ещё интересно, где в такой архитектуре хранилище?» — слой Repository в 95% случаев. И тем, кому нужна авторизация — дергают авторизацию по интерфейсу.
«Как вариант, приложение можно разбить на несколько разных модулей» — обычно, в приложении есть те или иные зависимости от общей логики, которые тяжело вынести.
«Как вариант, приложение можно разбить на несколько разных модулей (lerna/monorepo), контролируя тем самым их размер.» — возможно. Скажу честно, я таким не пользовался, а мой подход с чистой архитектурой лишь один из многих. Как я сказал, я лишь описываю свой опыт и лично я не люблю Redux, потому что для меня и моей команды было проще работать, используя другой подход. Но! Redux зарекомендовал себя и ничего против его использования я не имею. Так что я не отрицаю другие подходы, хотя и использую приведенную выше архитектуру, потому что она оказался самым удобным для нас решением.
*Impl — чтобы во время тестирования подсовывать классам интерфейсы. Редко эти *Impl меняются на что-то другое, поэтому подход исключительно ради удобства тестирования. Тем более, интерфейсы с одной реализацией они используются не везде — а только в ViewModel\Repository.
«описанный вами подход много ближе ложится в привычные бэкенд подходы» — как я написал в комментарии выше, эта архитектура изначально придумана для бэканда, потому что именно он обладает сумасшедшей сложностью. Но, помимо бэканда, ее можно применять везде, где возврастает сложность.
Опять же, как я написал выше, "основную силу архитектуры\тестирование приобретают в больших проектах с несколькими разработчиками, где нужно понимать и изменять чужой код". Если вы говорите, что это оверинжениринг для чего-то относительно маленького и даже среднего — я с Вами абсолютно согласен
«То, что вы написали — это прекрасно и часто абсолютно необходимо для очень сложных UI, и лютый overengineering для простых вещей, типа формы о двух инпутах.» — несомненно. В этом и суть.
«и лютый overengineering для простых вещей, типа формы о двух инпутах.» — разумеется, пример сильно надуманный, чтобы показать использование. Но! Если предположить, что этот код будет сильно меняться, а также писаться большим количеством людей — мы можем начать покрывать тестами на разных слоях, и избежать будущих проблем. Вообще, архитектуры\тестирование приобретают большую силу, именно когда проект пишется большим количеством людей на протяжении 1+ лет. Разработчики как раз начинают забывать свой код...
В общем, it depends. Но пример и правда с overengineering'ом, но только для того, чтобы объяснить архитектуру на примере.
«Плюс, если отойти чисто от архитектуры и перейти к вашему коду — мне, например, страшно не нравятся ваши ViewModelImpl.» — разумеется, чем больше код и сложнее логика, тем сложнее его читать — но глобальных проблем с этим я раньше не замечал. God-объектов в View Model я избегаю за счет Use Case'ов и внутреннего слоя. Можете привести пример, как бы Вы это реализовали?
Несомненно полно проектов, которым это не нужно. Но, как я написал в комментариях выше, с размером и увеличением количества людей начинают возникать проблемы. Также играет роль скорость изменения проекта (правок-то может быть и много).
Изначально я перешел на такую архитектуру, потому что логика в UI крайне тяжело поддается тестированию, а UI\ViewModel\Presenter слои начинают становиться God-объектами с дублирующимся кодом.
«ИМХО на бекенд/native приложения это ложится гораздо лучше.» — вообще, эту архитектуру придумали изначально для сложных бекенд приложений :). Поэтому часто для мелких фрондент проектов она избыточна — но, опять же, зависит от проекта. Как писать большой проект без чего-то подобного, оставляя его поддерживаемым, я не представляю (а ведь кто-то и fetch из onClick делает...)
В любом случае, интересно увидеть Вашу статью. Подчерпнуть что-то новое всегда можно (почему-то так выходит, что чистая архитектура у всех немного своя :)).
«У меня есть проблема с подбором разработчиков, большая часть кроме редакса ничего не знают и знать не хотят.» — честно говоря, я не сильный фанат Redux'a. Если приложение пишет больше, чем 1-2 человека — может начать путаница из-за сваливания состояния. Кто-то где-то что-то отправляет (не дай Бог из UI'я) — и искать это проблематично, все состояние находится в куче. К тому же, Redux особо-то и не отобразишь на UML диаграмме, например. Какой-нибудь Repository\Entity с шаблоном Observer лучше поддается понимаю и все состояние не сваливается в кучу. Это лично мое мнение, но я его избегаю. Аналогичный подход с Redux Saga — UseCase\Repository + View Model на async\await более красиво решают эту проблему и цепочку вызовов видно напрямую.
«Как вы решаете эту проблему?» — только учить. Специалисты стоят довольно дорого и проекты не всегда имеют для них бюджет. Поэтому объяснение + код ревью. Чистая архитектура не сложная вещь (вообще, сложные вещи в разработке с трудом приживаются и тяжело поддерживаются) — поэтому разработчики довольно быстро ее понимают и со временем начинают использовать без проблем.
Когда читал про типы мышления, провел аналогию с собой — что-то в этом есть…
А про блуждающий разум: думаю, каждый разработчик сталкивался с ситуацией, когда решение идеи приходит в душе или на улице, когда думаешь совершенно о другом :)
Но убил посыл «ну хотя бы несколько» :)
В ближайшие недели хочу разобраться во всех подходах, которые мне посоветовали\дополнили и дополнить свою архитектуру (на очереди — MobX).
Обязательно посмотрю Ваш репозиторий, не удаляйте его в ближайшее время, пожалуйста :)
«Вы перестарались, и цена фичи выросла раза в 4. Даже в Redux меньше „капусты“ и копипасты» — опять же, пример надуманный и здесь действительно много overengeneering'a.
«Высокий уровень входа для новичков (в меру высокий)» — не согласен. Вопрос изучения — максимум пару дней + поправка на общий опыт. В сравнении с тем, что пишут вообще без какого-либо подхода — я считаю, что архитектура выше большой шаг вперед. Собственно, и статью я написал потому, что не увидел других общепринятых подходов. Или только с акцентом на библиотеку, или вообще никак.
«Слишком много ручной работы, а следовательно высокая цена кода и большое пространство для формирования багов» — это тема для второй статьи. Собственно, во второй статье будет добавлен MobX и часть ручной работы отпадет.
Ключевая идея статьи в том, что серебряной пули нет — но есть такая, как описаны выше. И свои задачи она решает может не всегда идеально, но решает и в большинстве своем закрывает свои задачи.
Если у Вас будет время, можете рассказать, как бы Вы изменили архитектуру выше? Может просто созвониться и обсудить\пообщаться в Telegram. Я несомненно ищу пути улучшения подхода, который использую и статья — один из способов его улучшить в какой-то мере
На след. выходных я обязательно в нем разберусь. Спасибо, что потратили время и показали свое видение
P.S. Но отдельный момент — мой вариант, разумеется, не идеальный. Но он работает и понятен другим разработчикам, есть консистентность в проекте. Подходов много и мой — лишь один из них. Стремиться к идеальному, конечно, нужно, но идеальное — враг хорошего.
И Ваш код с MobX, как по мне, очень даже сильно дополнит архитектуру.
«Я больших проектах я рекомендую Атомарный дизайн» — можете продублировать ссылку? К сожалению, не открывается
«Я переписал это приложение, сделав ближе к тому, что я считаю чистой архитектурой» — на след. выходных я выделю время, чтобы разобраться, интересный подход
«И ещё интересно, где в такой архитектуре хранилище?» — слой Repository в 95% случаев. И тем, кому нужна авторизация — дергают авторизацию по интерфейсу.
«Как вариант, приложение можно разбить на несколько разных модулей» — обычно, в приложении есть те или иные зависимости от общей логики, которые тяжело вынести.
«Как вариант, приложение можно разбить на несколько разных модулей (lerna/monorepo), контролируя тем самым их размер.» — возможно. Скажу честно, я таким не пользовался, а мой подход с чистой архитектурой лишь один из многих. Как я сказал, я лишь описываю свой опыт и лично я не люблю Redux, потому что для меня и моей команды было проще работать, используя другой подход. Но! Redux зарекомендовал себя и ничего против его использования я не имею. Так что я не отрицаю другие подходы, хотя и использую приведенную выше архитектуру, потому что она оказался самым удобным для нас решением.
«описанный вами подход много ближе ложится в привычные бэкенд подходы» — как я написал в комментарии выше, эта архитектура изначально придумана для бэканда, потому что именно он обладает сумасшедшей сложностью. Но, помимо бэканда, ее можно применять везде, где возврастает сложность.
Опять же, как я написал выше, "основную силу архитектуры\тестирование приобретают в больших проектах с несколькими разработчиками, где нужно понимать и изменять чужой код". Если вы говорите, что это оверинжениринг для чего-то относительно маленького и даже среднего — я с Вами абсолютно согласен
«и лютый overengineering для простых вещей, типа формы о двух инпутах.» — разумеется, пример сильно надуманный, чтобы показать использование. Но! Если предположить, что этот код будет сильно меняться, а также писаться большим количеством людей — мы можем начать покрывать тестами на разных слоях, и избежать будущих проблем. Вообще, архитектуры\тестирование приобретают большую силу, именно когда проект пишется большим количеством людей на протяжении 1+ лет. Разработчики как раз начинают забывать свой код...
В общем, it depends. Но пример и правда с overengineering'ом, но только для того, чтобы объяснить архитектуру на примере.
«Плюс, если отойти чисто от архитектуры и перейти к вашему коду — мне, например, страшно не нравятся ваши ViewModelImpl.» — разумеется, чем больше код и сложнее логика, тем сложнее его читать — но глобальных проблем с этим я раньше не замечал. God-объектов в View Model я избегаю за счет Use Case'ов и внутреннего слоя. Можете привести пример, как бы Вы это реализовали?
Изначально я перешел на такую архитектуру, потому что логика в UI крайне тяжело поддается тестированию, а UI\ViewModel\Presenter слои начинают становиться God-объектами с дублирующимся кодом.
«ИМХО на бекенд/native приложения это ложится гораздо лучше.» — вообще, эту архитектуру придумали изначально для сложных бекенд приложений :). Поэтому часто для мелких фрондент проектов она избыточна — но, опять же, зависит от проекта. Как писать большой проект без чего-то подобного, оставляя его поддерживаемым, я не представляю (а ведь кто-то и fetch из onClick делает...)
«У меня есть проблема с подбором разработчиков, большая часть кроме редакса ничего не знают и знать не хотят.» — честно говоря, я не сильный фанат Redux'a. Если приложение пишет больше, чем 1-2 человека — может начать путаница из-за сваливания состояния. Кто-то где-то что-то отправляет (не дай Бог из UI'я) — и искать это проблематично, все состояние находится в куче. К тому же, Redux особо-то и не отобразишь на UML диаграмме, например. Какой-нибудь Repository\Entity с шаблоном Observer лучше поддается понимаю и все состояние не сваливается в кучу. Это лично мое мнение, но я его избегаю. Аналогичный подход с Redux Saga — UseCase\Repository + View Model на async\await более красиво решают эту проблему и цепочку вызовов видно напрямую.
«Как вы решаете эту проблему?» — только учить. Специалисты стоят довольно дорого и проекты не всегда имеют для них бюджет. Поэтому объяснение + код ревью. Чистая архитектура не сложная вещь (вообще, сложные вещи в разработке с трудом приживаются и тяжело поддерживаются) — поэтому разработчики довольно быстро ее понимают и со временем начинают использовать без проблем.