Как меня чуть не уволили за выбор React для корпоративного приложения

Original author: Razvan Dragomir
  • Translation

Предполагалось, что React облегчит разработку, но он создал препятствия


Летом 2018 года, мой босс, Эдриан, попросил меня присоединиться к его звонку по Skype с Джеймсом, техническим директором крупной канадской компании.

Пока мы узнавали друг друга, я понял, что Джеймс – умный парень с большими амбициями. Его видение заключается в миграции массивного десктопного приложения WPF в облако.

Мне нравится его дружелюбное отношение, и я могу сказать, что он готов сотрудничать с нами. У Джеймса уже есть партнёр по развитию в Индии, но ему не хватает опыта в создании веб-приложений. Казалось бы, что может пойти не так?




Мы с с моим боссом Эдрианом придерживаемся стандартного подхода к этой ситуации. У нас будет ещё несколько звонков, а затем мы начнём фазу открытия, в которой попытаемся понять общую картину происходящего и обнаружить нефункциональные требования. Вот основные моменты, на которых мы должны сосредоточиться:

  1. Приложение большое: более 220 страниц, большинство из которых – экраны для технического сопровождения, а около 20 % из них тонко настраиваются.
  2. Отображать большие объёмы данных, особенно в сетях со всевозможными функциями: группировка, возможность заморозить столбцы, расширить строки, настроить столбцы… ну, вы понимаете.
  3. Модульная архитектура, позволяющая нескольким командам работать над проектом одновременно.
  4. Это многолетний проект. Со временем будут добавляться новые функции.
  5. Автономный режим поддерживать не нужно.
  6. Новичков нужно адаптировать быстро, особенно разработчиков .NET, работающих над старым настольным приложением.

Как архитектор я создаю техническое предложение, которое содержит архитектурные детали, подход, план развития, руководящие принципы и, самое главное, технологический стек будущего приложения.

Джеймс неоднократно упоминал, что он хочет получить технологию будущего, и он не благосклонен к Angular, потому что, когда AngularJS устарел, эта технология приобрела плохую репутацию.

Итак, я уже успешно реализовал несколько небольших и средних проектов как на Angular, так и на React, поэтому не привязан к какому-то одному фреймворку. И я ощущаю, что оба фреймворка справятся с работой.

Для этого проекта я выбираю «React и Redux»… о чём буду жалеть два года спустя.

Для работы над доказательством концепции мы назначили команду из трёх разработчиков и через два месяца успешно завершили его. У нас был молниеносно быстрый пользовательский интерфейс, столь же быстрая сборка и высокая скорость разработки. Счастливы были все.

1. Разработчики .NET присоединяются к команде


После доказательства концепции настало время разработчикам из команды аутсорсинга заказчика присоединиться к нам. Мы ещё не начали встречи, чтобы поделиться знаниями о проекте, и технический директор прислал мне письмо по электронной почте со словами: «Привет, Рэзван. Нам действительно нужно встретиться завтра с моей командой аутсорсинга».

Итак, мы на встрече; технический руководитель устраивает мне засаду с вопросами:

  • «Где инъекции зависимости? Что ты имеешь в виду под „Не нужно никаких инъекций“? Вот пример: InversifyJS!»
  • «Функциональные компоненты»? Нет, нет, нет. Они нам не нравятся. Давайте работать с компонентами класса!"
  • «Почему эти функции просто болтаются в коде, и почему они не инкапсулируются внутри классов сервисов, чтобы сделать их статичными?»
  • «Где Retry Policy [прим. перев: политика повторения запросов] для API? Давайте реализуем её с помощью PollyJS».
  • «Почему в именах файлов тире, когда имена классов – PascalCase? Имена файлов должны отражать имя класса в файле, поэтому отныне будем называть их SomePageComponent.tsx».
  • И вопрос, который раздражает меня больше всего: «Как я могу запустить его в Visual Studio, а не в Visual Studio Code?»

Всё проясняется. Разработчики .NET хотят использовать руководящие принципы .NET и шаблоны проектирования в React. Я много раз видел разработчиков, которым трудно адаптироваться к новым технологиям, так что не боюсь ввязываться в дебаты о том, почему для React эти паттерны необычны.

Но в данном случае технический директор поддерживает свою команду, это нормально. Он знал меня всего два месяца, а со своей командой работал много лет. Я должен пойти на компромисс и согласиться с их предложениями.

И тут я осознал, что React не дружественен ни к Java, ни к .NET разработчикам. Angular в этом случае был бы лучшим выбором из-за схожих шаблонов проектирования.

2. Дело не обходится одним React


React – это библиотека, не имеющая мнения; это означает, что у нее нет мнения о том, как решать проблемы, которые касаются всех аспектов. Таким образом, это ваша обязанность и вашей команды – выработать мнение о том, что и как сделать и особенно о том, какие другие библиотеки вы хотите использовать. Конечно, вы будете применять сторонние библиотеки, потому что не хотите изобретать колесо. И в React имеется множество разных вариантов.

Для подтверждения концепции у меня уже было мнение о том, как нам следует решать большинство сквозных проблем. Теперь их пришлось перепроверять с новыми членами команды. Это минимальный список тем для обсуждения:

  • Какой маршрутизатор следует использовать?
  • Что кроме Redux мы должны использовать для асинхронных действий? Thunk? Saga?
  • Должны ли мы использовать Axios или fetch API в браузере?
  • Redux-Forms, Formiq или Final-Form?
  • Styled-Components, makeStyle, SASS или чистый CSS?
  • А что с библиотекой интернационализации?

Так что, принимая эти решения, мы провели ещё три недели. Я уже слышу, как вы воскликнули: «Мужик! Не может быть, чтобы на выбор этих библиотек потребовалось три недели!»

Ну… добро пожаловать на корпоративные проекты. Есть множество решений. Для каждого из них вы должны создать критерии принятия решения, провести исследование, проверить результаты, создав доказательство концепции, представить результаты, задокументировать всё в журнале принятия решений и поддерживать библиотеки в актуальном состоянии. Это занимает сумасшедшее количество времени, и это совсем не весело.

И я даже не учитываю, сколько времени каждый разработчик тратит на изучение всех этих сторонних библиотек. Я никогда не видел двух проектов React с одинаковыми зависимостями, структурой проекта и руководящими принципами. Это означает, что знания не могут передаваться от проекта к проекту, как это может быть в случае Angular или Vue.

После трёх недель без прогресса во внедрении функционала из юзер-стори технический директор забеспокоился.

3. Хуки React обретают популярность


Через девять месяцев мы создали более 50 страниц. Разработчики заметили, что функциональные компоненты ничем не уступают компонентам классов, и начинают использовать их. Итак, теперь проект не следует исходным рекомендациям по кодированию. Всё это больше похоже на личный выбор каждого разработчика. И для меня это нормально.

React Hooks обретают популярность. Разработчики испытывают смешанные чувства.  Одни обижаются на предположение, что классы вводят в замешательство людей и машины, тогда как другие с энтузиазмом относятся к новому паттерну кодирования.

Все сторонние библиотеки, которые мы используем, добавили поддержку хуков, и похоже, что весь мир React движется в этом направлении. Так что же делать нам? Должны ли мы отклониться от первоначальных руководящих принципов кодирования и добавить третий способ реализации компонентов? Вернуться назад и перенести существующие страницы и компоненты в хуки уже невозможно!

Команда выступает за использование хуков Redux, потому что нет необходимости использовать Redux connect() и отделять «глупые компоненты» от контейнеров. Это имеет смысл, и мы согласились с тем, что отныне новые страницы и компоненты будут использовать хуки. Старые страницы останутся как есть.

Итак, у нас есть три разных способа писать проект. И нет последовательности.

Что ещё хуже, некоторые разработчики начинают настаивать на том, чтобы больше не использовать Redux, а вместо него применять useState. Это означает, что мы разрушим идею единого глобального состояния.
Функция Suspense всё ещё экспериментальная. Я забеспокоился о том, что произойдёт, когда она войдёт в релиз официально.

4. Разработка замедляется


Когда мы настроили непрерывную интеграцию (CI), сборка, включая npm install, занимала около трёх минут. Но теперь, спустя год, она занимает около 15 минут.

Мы также должны были настроить Node.js и поставить оперативную память 4 ГБ, потому что 2 ГБ уже не хватало. Это небольшая проблема. Что касается начавшихся жалоб на время сборки, горячая перезагрузка перестает работать после 45–60 минут разработки, а перезапуск занимает более пяти минут – особенно у разработчиков с Windows (системы Linux, по-видимому, намного быстрее в смысле Node.JS). Иногда разработчикам на Windows приходится полностью удалять node_modules и снова загружать зависимости, потому что иначе они просто не работают.

Чего ещё можно ожидать, когда в node_modules более 1200 зависимостей общим размером 600 МБ?

В смысле корпоративного приложения всё сводится к затратам. Допустим, разработчик с почасовой ставкой 40 долларов в час должен перезапускаться шесть раз в день. Шесть раз в день умножаем на пять минут и на 240 рабочих дней в году, затем на 40 долларов в час и на восемь разработчиков = 38 400 долларов в год. Это небольшая сумма для предприятия, но это хороший ежегодный бонус для спонсоров проекта. В конце концов, сумма равносильна совершенно новой Tesla Model 3.

5. Redux-Saga медленно умирает


Большинство разработчиков не согласны со мной, но я ощущаю, что большая часть бизнес-логики находится внутри асинхронных действий Redux. В большинстве случаев асинхронные действия – единственное место, где можно выполнять проверку, вызовы API, обработку ошибок, запускать мутации redux или тостер уведомлений. Если это не бизнес-логика в интерфейсных приложениях, то что же тогда это такое?

Решение использовать Redux-Saga оказалось плохим потому, что оно добавляет ненужную сложность. Достаточно хорошо подходил бы Thunk.

В корпоративных приложениях вам необходимо время от времени обновлять и перепроверять зависимости. Это хорошая практика, потому что важно иметь обновления безопасности, улучшения производительности и небольшие инкрементные изменения API, при этом надеясь на отсутствие критических изменений. Похоже, что Redux-Saga в этом смысле осталась позади. Последнее обновление было более года назад, количество issues на GitHub растёт, и никто не исправляет их.

Разработчики любят React по трём причинам: простота, гибкость, экосистема. Команде React нравится экспериментировать с новыми идеями, но это убивает экосистему! Они должны проявить смелость и взять на себя вину за это!

Действительно, React в основном обратно совместим, а экосистема вокруг React – нет. Разработчики и сторонние библиотеки всегда будут использовать новейшие функции и шаблоны архитектуры, а старые эксперименты останутся умирать. Это не должно быть проблемой для малых и средних проектов, потому что вы можете легко адаптироваться. Но для больших многолетних проектов эти эксперименты могут отбить у клиента желание работать с продуктом.

Уже сентябрь 2020 года, и я решаю включить «React-Saga» в результаты оценки рисков, предназначенные для технического руководящего комитета.

Поскольку 30 % бизнес-логики содержалось внутри Saga, я посчитал это высоким риском. Когда мы начинали проект, технический директор вышел из себя и обвинил меня в том, что я принимал неверные решения.

Это была просто искра, в которой нуждался продакт-менеджер. Эта искра дала менеджеру возможность задавать вопросы, например:

  • «Почему мы должны тратить столько времени на обновление библиотек?»
  • «Почему разработка замедляется?»
  • «Почему приложение стало глючным и нестабильным?»

Ситуация доходит до уровня руководства. Много часов я провожу в поисках доказательств того, что мы приняли лучшее на тот момент решения, – не так, как мне хотелось бы провести выходные.

Спустя несколько посвящённых ретроспективе встреч мы снова плывём по спокойным водам. В конце концов, проект почти готов и близок к переходу в режим поддержки.

Заключение


Я люблю React. Я работаю с ним на всех своих личных проектах и с удовольствием порекомендую его в смысле новых инициатив на работе. Однако после этого неприятного опыта, который случился со мной, я не буду поощрять его использование для корпоративных приложений. Только не это. И я не одинок в этом.



image



SkillFactory
Школа Computer Science. Скидка 10% по коду HABR

Comments 333

    +2
    Спасибо. Интересный взгляд. Можно ссылку на оригинал?
      +6
      В переводах ссылка на оригинал под названием поста.
      image
        +6
        спасибо. на мобилке этой фичи нет
          +1
          Странно… Проверил на мобилке (Android), через Chrome — ссылка есть.
            0

            Просто во вкладке или в режиме PSA?

            • UFO just landed and posted this here
              0
              [deleted]
                +3
                я смотрел эту статью в приложении. Проверил сайт, да там есть ссылка. Буду знать.

                image
                  +2
                  в приложении на андроиде нет
              +1
              Это перевод, под названием статьи есть ссылка на оригинал.
                +2
                Я смотрел в приложении. Там нет.
                +2
                В начале статьи же кликабельная надпись про оригинал
                  +3
                  Я смотрел в приложении. Там нет.
                    +1
                    Да, баг, наверно. В мобильном браузере, кстати, все нормально)
                      +5

                      Не баг, а не реализовано. На приложение вообще официально забили.

                      +1
                      FYI приложение давно не поддерживается qna.habr.com/q/731363
                  +19
                  Выглядит так что неуправляемое резкое расширение команды создает проблемы, а не React
                    –5

                    Вот я не совсем соглашусь с Вами, а соглашусь с автором… у меня не большая команда… и технологию я оцениваю так… если через более пол-года возвращаемя к коду расшририть функциональность… поправить баг… то для примера java(erp система)… разработан "целый космос " и всегда к коду возвращаться легко… легко дополнить и нет побочных эффектов.возможно из-за принципа концепции ленивой подгрузки кода… А вот в реакте небольшие проектики.(не то что у автора статьи) и вернуться к коду через время(React+Redux) или что-то дополнить… Это боль… я сменил стек .

                      +9
                      У меня как раз наоборот впечатленеие — если есть цельное видение проекта, как мы его пишем, куда что кладем, то проблем нет. Проблемы со слов автора начались когда пришла команда, начала какую-то хрень вводить, а у него не хватило сил и видения «как это должно быть», чтобы остановить их от внедрения чуждых для реакта вещей
                        0

                        И что сейчас? Ангуляр?

                          –8

                          Вы знаете я как предприниматель в ИТ… рассуждаю просто(Мой взглаяд может не подходить для крупного бизнеса)… с точки зрения уменшения ресурса(технического, административного, по сопровождению)… Мои проекты связаны с базами данных(автоматизацией бизнеса)… для малого и среднего.
                          И в зависимости от ситуации или 1.Oracle Apex(Это быстрая среда для разработки бизнес приложений… мне кажеться быстрее нельзя можно только повтороить).
                          2.Или(если проект будет иметь много отраслевых подрешений) PHP+HTML контролы на jQuery

                            +4

                            2 Со временем всё сложнее будет находить специалистов, готовых с этим работать. Особенно вдолгую.

                              0
                              Oracle Apex(Это быстрая среда для разработки бизнес приложений… мне кажеться быстрее нельзя можно только повтороить)

                              Быстрая среда для разработки бизнес-приложений — 1С: Предприятие. Не думаю, что в Oracle Apex можно быстрее что-то сделать.

                            +1
                            Приведите, пожалуйста, пару примеров. Почему возвращаться к java коду легко и какие проблемы при доработках в стеке React+Redux?
                              –5

                              Именно почему я не знаю...(тут же была ремарка для меня)… это по моему опыту… есть проекты на react(Это POS кассы на планшете… магазин ресторан), ЕГАИС Проверка марок(тоже чтоб мобилу использовать… тут React к месту) На java вообще большая кросспоатформенная Desctop ИС.с дублирующими web мордами для некторых отраслевых процессов(vaadin Это java). и oracle apex.Так вот если вдруг(для меня) нужно вернуть и доработать react… Это всегда выход из зоны комфорта… Пока пишешь(React)… держишь в уме "нить" вроде нормально. Решение выпущено работает… вернуться к нему… всегда жалеешь ,-на кой я выбрал React в этом решении… Возможно какая-то эфимерная нечёткая концепция у React… что потом "концы" сложно собрать в кучу".(Сугубо по моему мнению)

                            +1
                            … или невозможность настоять на своем видении, особенно когда ответственность за продукт так же на тебе
                              +2
                              Согласен. До сих пор ищу эту грань — где невозможность, а где я просто «не продал» решение нужное.

                              Кажется что в момент прихода новой команды можно было бы озвучить что вот мол «они новички в React, за мной право на design review».

                            –19

                            У меня только один вопрос — почему технические решения принимает человек, знающий лишь полтора фреймворка?

                              +4
                              А сколько он их должен знать, по-вашему? Что еще было в экосистеме JS, кроме React и Angular, что стоило рассмотреть для подобного размера приложения? Даже Vue в 2018 году был не настолько популярен.
                                –3

                                Чтобы принимать взвешенное решение нужно иметь достаточно широкий кругозор, не ограничивающийся парой наиболее популярных вариантов.

                                  +6
                                  Никто не говорит, что он не знал больше ни о чем, говорится, что Angular и React в бою были автором проверены. Боюсь, что при «альтернативном» выборе статья могла бы называться в стиле «Как меня чуть не уволили за выбор Svelte для корпоративного приложения» :)
                                    –27

                                    Не пробовал в бою = не знал.
                                    За выбор любого высокоуровневого фреймворка ($mol, ExtJS, SAPUI5, да хоть 1С) его бы только похвалили.

                                      +11

                                      Если учесть все сотни фреймворков которые существуют в JS, а по вашему их надо все попробовать в бою, то надо каждый новый проект писать с использованием нового фреймворка? Или сразу в одном проекте использовать 2-3 чтобы время сэкономить?

                                        –19

                                        Типов фреймворков от силы десяток наберётся. Достаточно ознакомиться с представителем от каждого.


                                        Если у самого не хватает опыта для принятия такого решения — всегда можно нанять того, у кого этот опыт есть для консультации. А не обрекать "большой и долгий проект" на кучу легаси и рефакторинги в первые же пару лет.


                                        Самомнения у таких вот "любителей реакта" много, а совести — нет.

                                          +10
                                          Люди с опытом обычно понимают, что проблема не в фреймворках.
                                            –7

                                            Проблема в архитектуре, которая этими самыми фреймворками форсируется. И их экосистеме, которая не позволяет сесть и поехать, а требует кучу бессмысленных приседаний.

                                              +6
                                              Если смотреть на долговременную перспективу лет так в 10, то любая активно развивающаяся апликуха имеет тенденцию года через 3-4 начинать превращаться в тыкву по множеству причин. И архитектура среди них даже не в top 3.
                                                0

                                                Тут у людей уже через год тыква начала получаться. И чем дальше, тем тыквеннее.

                                                  0

                                                  Расскажите про тыкву ребятам из .NET или Java Enterprise которые поддерживают проекты часто больше 7 лет.

                                                    +1
                                                    У самого 3 таких проекта на поддержке. И это тыква. За такое время от первоначальной архитектуры и светлых задумок мало что остаётся, всё зарастает мхом.
                                                      0

                                                      Странно. А у нас архитектура устаканилась когда прояснились реальные требования — и вот уже лет пять как значительно не меняется. Проекту, собственно, чуть больше десяти лет.

                                                  +3

                                                  Вот реакт как раз ничего особо не форсирует

                                                    +1

                                                    Ну конечно..


                                                    • push семантика.
                                                    • отсутствие двустороннего связывания.
                                                    • необходимость ручного прокидывания: классов для стилизации, идентификаторов для привязки тестов, контекста для локализации и тп.
                                                    • невозможность сделать нормальную инверсию контроля.
                                                    • невозможность рефлексии компонента.
                                                    • невозможность переноса компонента в другого родителя без его пересоздания.

                                                    И это список можно ещё долго продолжать.

                                                      +5

                                                      Просто перестаньте относиться к реакту как к тому, чем он не является — полноценному фреймворку.


                                                      Ок. Реакт навязывает единственную вещь: вью — чистая функция от переданных свойств и, опционально, стэйта и рендерится автоматически при их изменении в терминах JS. Если собираетесь с этим бороться, то это будет больно.

                                                        +3

                                                        Обязательно, как только перестанут врать про "у нас проект на Реакте", скрывая от руководства, что на самом деле "проект на кривом велосипеде, слепленном из Реакта и ещё 10 библиотек и скрученных синей изолентой". Я много проектов повидал "на Реакте" — везде одни и те же проблемы. И они очевидны были с самого начала.


                                                        Начнём с того, что вьюшки в Реакте не являются чистыми, кроме разве что совсем тривиальных. А закончим тем, что больно бывает лишь при отсутствии идемпотентности, которую обеспечивает не чистота, а реактивность.

                                                        0
                                                        необходимость ручного прокидывания: классов для стилизации

                                                        Но зачем? Стилизация компонентов — ответственность самих компонентов, а возможная вариативность — это часть явного интерфейса компонента, которой в пропсах самое место. Да и то, не факт, что там нужны именно CSS-классы, а не флаги или другие высокоуровневые параметры.
                                                          0

                                                          В разных контекстах необходимо менять разные особенности визуализации компонента. Попытка выразить всё многообразие кастомизаций в пропсах выливается в свой недо css. За примерами можете посмотреть любой более-менее матёрый компонент. Фронтенд ходит по кругу, наступая на одни и те же грабли с каждым витком.

                                                            0
                                                            В разных контекстах необходимо менять разные особенности визуализации компонента.

                                                            Здесь проблематика аналогична модификаторам в BEM: очень тонкая грань между кастомизацией и вообще другим отображением. Во втором случае — это разные компоненты, в которых можно легко переиспользовать логику, обернутую в хук.

                                                            А просовывание классов ломает саму идею компонентного подхода — оборачивающий код жестко завязывается на низкоуровневую специфику отображения своего дочернего компонента.

                                                            За примерами можете посмотреть любой более-менее матёрый компонент.

                                                            Матерые компоненты (DevExtreme, к примеру) имеют богатые настройки отображения через параметризацию, хотя и поддерживают передачу css-классов в некоторых местах.
                                                              0
                                                              Во втором случае — это разные компоненты, в которых можно легко переиспользовать логику, обернутую в хук.

                                                              Это не работает, когда у вас компонент чуть сложнее кнопки. Ну, например, компонент "навигатор по WebDAV" и вам надо в конкретном приложении сделать, чтобы иконки фалов увеличивались при наведении на имя файла. А компонент этот поддерживаете вообще не вы. Сколько итераций потратите на реализацию этой дизайнерской задумки?


                                                              Матерые компоненты (DevExtreme, к примеру) имеют богатые настройки отображения через параметризацию

                                                              Эти настройки обычно покрывают лишь 60% потребностей проекта. Что делать с остальными 40%? Писать фичереквест и ждать с моря погоды? Форкать, вставлять костыли и поддерживать их при каждом обновлении? Форкать, неделю разбираться как адекватно сделать нужную тебе фичу, после чего ещё месяц бодаться с мейнтейнером, чтобы он принял мерж реквест?

                                                                +1
                                                                вам надо в конкретном приложении сделать, чтобы иконки фалов увеличивались при наведении на имя файла. А компонент этот поддерживаете вообще не вы.

                                                                Предлагается изменить внутреннее поведение компонента. Если так, то логичнее было бы его в самом деле форкнуть и наделить необходимым функционалом, а не патчить результат извне. Не факт, что будет дороже, но 100% — надежнее.

                                                                Форкать, вставлять костыли и поддерживать их при каждом обновлении?

                                                                Внедряясь во внутреннюю структуру разметки и стилей так же никто не сможет гарантировать, что при следующем обновлении все не поломается.
                                                                  –1

                                                                  Примечательно, что на поставленные вопросы вы так и не ответили.


                                                                  А что если...


                                                                  image


                                                                  … можно построить архитектуру так, чтобы:


                                                                  1. Минимизировалась вероятность поломки при обновлении.
                                                                  2. При поломке падала бы сборка, а не появлялись скрытые баги.
                                                                  3. Изменения хранились бы в репозитории потребителя компонента, а не требовались форки.
                                                                  4. Достаточно было бы пары простых строчек кода, а не головоломные портянки.
                                                                    +1
                                                                    на поставленные вопросы вы так и не ответили.

                                                                    На все поставленные вами вопросы вроде бы ответил прямо или косвенно. Давайте еще раз:

                                                                    Сколько итераций потратите на реализацию этой дизайнерской задумки?

                                                                    Тут вы число ждали? Вслепую оценивать объем работ как-то странно.

                                                                    Что делать с остальными 40%?

                                                                    Искать более подходящий компонент или форкать имеющийся.

                                                                    можно построить архитектуру так, чтобы:

                                                                    Предлагаемый подход с патчингом удовлетворяет лишь крайнему пункту.
                                              0
                                              Вы либо никогда не делали фронтенд, либо троллите. Время миллиона фреймворков прошло в 2016. Сегодня — Ангуляр для bloody enterprise, Vue для fast kick-off, но заплатите позже качеством, React — собери сам, и будет зависеть от того кто собирал. Все остальное (Свелты и прочие) — игрушки для гуру программирования, а не приложений на 120 страниц.
                                              +32
                                              Я буквально сидел и ждал, как скоро вы упомяните $mol, это же единственная причина вашего появления тут, правда?
                                              Не то чтобы это было плохо в рамках одной ветки комментариев, но к сожалению эта назойливая самореклама стала регулярной.
                                                –22

                                                Я там ещё троих упомянул, если вы не заметили. Любой из них подошёл бы для задач автора лучше Реакта. И даже лучше Ангуляра.

                                                  +5

                                                  Для корпоративного приложения, для которого даже Реакт — слишком быстро развивающаяся и меняющаяся штука?

                                                    –4

                                                    Реакт так-то довольно медленно именно развивается, не смотря на частые изменения в апи и, особенно, экосистеме. Тот же $mol за то же время куда более существенно развился (появилось и исчезло квантование, появилась виртуализация, полностью переработана система реактивности, дважды), при этом для прикладного разработчика мало что поменялось. Реакт же тем временем всё никак не допилит фичи, которые были в $mol изначально (Suspense, Dependency Tracking, Context).

                                                      +6

                                                      Вот вы постоянно пытаетесь пиарить $mol, и я очень даже допускаю что он очень крут как фреймворк. Но вы постоянно это делаете настолько агрессивно, с позиции "вы все дурачки и не лечитесь", что никакого желания даже смотреть в ту сторону не хочется. Советую вам пиаром заниматься не с негативной а с позитивной стороны.

                                                        –7

                                                        Я уже года 3 как не пиарю $mol, а делюсь идеями, наработками и результатами анализа. Тем не менее:


                                                        Но вы постоянно это делаете настолько агрессивно, с позиции "вы все дурачки и не лечитесь", что никакого желания даже смотреть в ту сторону не хочется.

                                                        Это довольно дурацкий ход мысли, показывающий иррациональность вашей позиции.

                                                          +5

                                                          Ну было бы странно если бы вы со мной сразу согласились :)

                                                      +1

                                                      ExtJS для такого вполне зашёл бы, разве нет?

                                                        +1
                                                        ExtJS для такого вполне зашёл бы, разве нет?

                                                        Верно. ExtJS — это свыше 500 классов. Что-то вроди Дельфи для фронтенда.
                                                        И ExtJS — платный. Но это как-раз для энтерпрайз проекта.

                                                        Короче — ExtJS — это то что как-раз нужно для энтерпрайз проекта — повиснуть на нём и платить и платить и платить (а также ждать когда решат проблему, ждать и ждать) — короче — хотите надолго зависнуть и дорого платить — выбирайте ExtJS.

                                                        Единственно ExtJS пользуется менее — 0,5% разработчиков — но свыше 500 классов! — Что вам ещё нужно то? Особенно если вы что-то делаете для внутреннего(!) продукта употребления в банке, к примеру!
                                                          +1

                                                          Ну я вот один из тех 0.5%, скрывать не буду.


                                                          Вы кроме числа классов и платности про него что-то ещё знаете? Например, про огромное количество настроек и надстроек? Или про то, что его формат функциональных таблиц толком никто не повторил с тех пор, и именно из-за таких таблиц проект вообще до сих пор шевелится? Или хотя бы про то, что все 500 или сколько их там классов образуют единую систему, а не дикую портянку из слабосвязанных и зачастую несовместимых между собой лефтпадов, которые нынче в моде?
                                                          Уж поверьте, я работал с ExtJS от старых версий и до довольно новых, а сейчас соседняя команда с таким скрипом пытается на реакт+mobx повторить всё что в прежнем UI подключалось парой строчек — что от их стараний полсистемы шатает. И время билда только за счёт jsx у нас почти на 40% подскочило, и это ещё ни один наш модуль не стал полноценно переходить на молодёжные фреймворки, которыми пользуется больше 0,5% разработчиков.

                                                            –2
                                                            соседняя команда с таким скрипом пытается на реакт+mobx повторить всё что в прежнем UI подключалось парой строчек

                                                            О да, это вершина программирования. «Программировать» галочками и 2мя строчками копи пасты из примеров с сайта.
                                                            Кто же в здравом уме будет сам реализовывать алгоритмы и тем более вообще писать код, это удел дурачков и неудачников.
                                                            Вот они там и мучаются на своими реактами и т.п. ха-ха.
                                                            А вы делите пьедестал почета с 1Сниками и гордитесь этим =)
                                                              +8

                                                              Вы сейчас пытаетесь унизить оператора экскаватора тем, что он не копает котлованы лопатой. Во тупой, да.

                                                              –1
                                                              Вы кроме числа классов и платности про него что-то ещё знаете?
                                                              Да, работал с ним до той поры пока он был бесплатным. До 5- версии.

                                                              Например, про огромное количество настроек и надстроек?
                                                              Огромное. Согласен. Да и классов поди уже свыше 700 там. Если брать по 10 методов — то под 7000 методов то будет то, поди.

                                                              Или про то, что его формат функциональных таблиц толком никто не повторил с тех пор, и именно из-за таких таблиц проект вообще до сих пор шевелится?
                                                              Да, если кому надо таблицы из Excel в веб закинуть, то возможно, не бесплатно, можно попробовать ExtJS — но сам я не использовал таблицы то. Не из банка я.

                                                              Или хотя бы про то, что все 500 или сколько их там классов образуют единую систему, а не дикую портянку из слабосвязанных и зачастую несовместимых между собой лефтпадов, которые нынче в моде?
                                                              Верно. Никакой моды. Всё кондово сделано. Как в Дельфи!

                                                              ещё ни один наш модуль не стал полноценно переходить на молодёжные фреймворки, которыми пользуется больше 0,5% разработчиков.
                                                              Согласен. Банки надёжно «подсели» на этот ExtJS, тем более что у банков денег хватает на лицензию то.
                                                              А может уже не 0,5% а меньше на рынке то у этого «динозавра» у ExtJS — я только видел что ниже плинтуса.

                                                              Но для банков это неважно — да и в банках дельфинариков хватает, чтобы освоить ExtJS то. Он им будет привычен. Кондовый ООП — это что-то!

                                                              И я не шучу!

                                                              (Разработчики ExtJS конечно наклепали и React библиотеку СВОИХ компонентов, то это мода, не более чем. На это можно, наверное не обращать внимание. — Кондовый дельфиподобный ООП — ExtJS — что ещё нужно банковскому программисту?)

                                                              И я не шучу!
                                                                +1

                                                                Ну да, настоящие хипстеры, которые пишут на редаксе готовы работать исключительно на магазины по продаже вейпов. Для всего остального есть более адекватные технологии, но всё, кроме вейпов и не нужно. А если для интернета нужны только магазины по продаже вейпов, а их лучше всего писать на редаксе, то настоящий хипстер сразу смекнёт, что ничего кроме редакса в интернете не нужно!

                                                                  +2
                                                                  но сам я не использовал таблицы то.

                                                                  Но хаять их (выходит, безосновательно) это вам не мешает.


                                                                  Так всё-таки, какие конкретно претензии к фреймворку? Меня количество классов и методов вообще не интересует (тем более что с количеством методов внутри вы ошиблись примерно на порядок), и у меня нет отвращения к Дельфи, ООП и тем, кто с этими технологиями работает.

                                                                    0

                                                                    Вы не понимаете. Сейчас не модно писать понятный и поддерживаемый код. Сейчас нужно побольше динамики, побольше меняющихся свойств, чтобы каждый раз, когда ты смотришь на переменную — она как женщина: Загадка!


                                                                    А ещё ни в коем случае не реюзать код. Всегда проще закопипастить, ведь он может чем-то отличаться! Так и изменения вносить проще!


                                                                    Ну и, конечно, "классы"! Это ведь мерзкое слово, почти как "сексист"! Даже если логично использовать класс — ты должен вывернуться и сделать то же самое, но без использования слова "класс".

                                                                      0
                                                                      Но хаять их (выходит, безосновательно) это вам не мешает.

                                                                      ААААААААААААААААААААААААААААААААА!!!
                                                                      Где я хаил таблицы? Какими словами или знаками препинания?
                                                                      Я не работал с таблицами в ExtJS — ну НЕ пересекался никак.
                                                                      Надо вам ООП как у Дельфи или таблицы — и заказчик в состоянии платить лицензию — используйте ExtJS.
                                                                      Проблемы?

                                                                      Меня количество классов и методов вообще не интересует (тем более что с количеством методов внутри вы ошиблись примерно на порядок)
                                                                      Ну а что ещё можно сказать о ExtJS? Уже всё сказано.
                                                                      Ошибся я в какую сторону? 10 методов на класс — это много — там 100? Или мало — там по 1 методу на класс то?
                                                                      А кроме методов у классов есть ещё и СВОЙСТВА — по 10 на класс.
                                                                      Итого — 10 000 методов и свойств на 500 классов, примерно.
                                                                      У вас другие цифры? — так озвучьте.

                                                                      и у меня нет отвращения к Дельфи, ООП и тем, кто с этими технологиями работает.
                                                                      А я как-то обозначил отвращение к Дельфи и ООП?
                                                                      Да у меня нет никакого отвращения и к Коболу!

                                                                      Я написал что дельфинарики (программисты на Дельфи) вполне смогут ЛЕГКО начать писать код на ExtJS — там такой же кондовый (то есть ОСНОВАТЕЛЬНЫЙ) ООП что изучали в универах с середины 90-х годов прошлого века.

                                                                      И я думаю, что дельфинарики ещё есть в банках то! Куда они смогли уйти то? На Java?

                                                                      Я уверен что и функциональщина и даже Redux можно использовать в ExtJS (я подписан на рассылку ExtJS и там время от времени появляются упоминания что что-то такое делается и в ExtJS).

                                                                      Так что НЕ надо на меня нападать за ExtJS. Я уже всё написал что знал про него.
                                                                      Ну не пользуется ExtJS никакой популярносттью сейчас как и Дельфи — но если это кого-то не пугает, и не пугает плата за лицензию — то почему бы и нет?

                                                                      Но, похоже, если я сейчас напишу что «два плюс два равно четыре», вы напишите мне в ответ (поставив минус посту) что типа Я ОБИДЕЛ ЦИФРУ ПЯТЬ!

                                                                      Не надо так.
                                                                        0
                                                                        У вас другие цифры? — так озвучьте.

                                                                        Меня вообще не цифры интересуют — а, например, то, что это цельная библиотека компонентов, с хорошим фактически никем не повторённым функционалом таблиц, при этом достаточно гибкая, чтобы на её базе хорошо работали совершенно по-разному выглядящие интерфейсы (несмотря на "кондовый ООП") — и даже допускающая степень модульности архитектуры, при которой вышестоящие интеграторы могут добавлять функционал в существующие компоненты/формы без создания компонентов "таких же, но с перламутровыми пуговицами" (во многом — благодаря "кондовому ООП").


                                                                        А я как-то обозначил отвращение к Дельфи и ООП?

                                                                        Да, прямо в следующем абзаце сообщения.


                                                                        Я уже всё написал что знал про него.

                                                                        У… Честно говоря, не густо. Похоже, я могу больше недостатков в ExtJS назвать, а я же даже на рассылку не подписан. А самое главное — вы так и не написали, чего вам в нём настолько не нравится, что такие эмоции сквозь текст проступают, а ведь именно такой был вопрос.

                                                                          0
                                                                          Надо вам ООП как у Дельфи или таблицы — и заказчик в состоянии платить лицензию — используйте ExtJS.

                                                                          1. Есть и бесплатные альтернативы ExtJS
                                                                          2. Если заказчик в состоянии платить за проф программистов, которые месяцам велосипедят то же самое на Реакте, то на лицензию у него есть деньги и подавно.
                                                                            0

                                                                            2) У некоторых заказчиков разное отношение к тратам на создание своей интеллектуальной собственности и на лицензирование чужой.

                                                                              0

                                                                              Речь шла про состояние платить, а не про желание.

                                                                                +3

                                                                                Некоторые заказчики в состоянии вкладываться в ФОТ, но не в лицензии. 10-долларовые лицензии приходится месяцами выбивать для разработчиков с зарплатами в тысячи долларов, хоть на свои покупай команде

                                                                              –1
                                                                              Есть и бесплатные альтернативы ExtJS…
                                                                              на лицензию у него есть деньги и подавно.

                                                                              Тут налицо противоречие — если есть бесплатные альтернативы то зачем платить?

                                                                              Думаю «мощнее» по кондовости ООП и количеству классов нет альтернативы ExtJS.

                                                                              Похоже главная причина почему ExtJS никто не рекомендует — это исчезающе малое число программистов желающих использовать ExtJS (и возможно и его кондовое ООП) на фронтэнде.

                                                                              ExtJS спасают от забвения, похоже, банки, «подсевшие» на него до введения платной лицензии.
                                                                                0
                                                                                ExtJS спасают от забвения, похоже, банки, «подсевшие» на него до введения платной лицензии.

                                                                                Для маленького примерчика, все веб-морды всех продуктов Synology написаны на ExtJS. Не стоит юродствовать.

                                                                                  0
                                                                                  Для маленького примерчика, все веб-морды всех продуктов Synology написаны на ExtJS.
                                                                                  ExtJS для интранета с кондовым ООП вполне окей.
                                                                                  Интранет — это и Synology и внутрибанковский продукт и прочее.

                                                                                  То есть всем кто уже подсел.
                                                                                  Ну, пишут же и на Дельфи сейчас. Кто уже подсел.
                                                  +1
                                                  журнал принятия решений? можн опочитать об этом поподробнее? Какие инструменты для этого используется?
                                                    +2

                                                    Любая вики-система. Обычно это конфлюенс. По каждому вопросу создаёте страничку, где описываете текущую ситуацию, цели, возможные варианты, их отличительные особенности и принятое по результатам этого анализа решения.

                                                      0
                                                      Architecture Decision Record (ADR).
                                                      Используется мозг и память :)
                                                      +5
                                                      Пришли злые .net-разработчики и сломали React, плак-плак. А всего лишь начали задавать вопросы.
                                                      Сначала мы жалуемся что «Почему эти функции просто болтаются в коде, и почему они не инкапсулируются внутри классов сервисов, чтобы сделать их статичными?», а потом плачем о том что саги разбухли и непонятно что с ними делать. А понимание того что нужны сервисы — автоматически ведет к пониманию того что DI нужен если не в компонентах, то в самих сервисах и сагах — точно. Плач о именованиях файлов вообще клоунада, но напомню, что при одинаковом названии класса и файла — искать фултекст серчем — гораздо удобнее.
                                                        +4
                                                        С одной стороны .net разработчики во многом правы (жить с DI, retry лучше чем без них), с другой стороны они продавливали своё мнение без учета специфики реакта.

                                                        Например требование class based components на самом деле продиктовано желанием использовать inversifyjs в режиме аннотаций, когда function based components потребовали бы явно обертывать функцию перед экспортом или использовать реактовский аналог service locator-a (context).

                                                        Требование retry policy через PollyJS так же не совсем обычно для экосистемы реакта (есть другие инструменты).

                                                        И это без учета претензий по скорости разработки/билда и качеству собственноручно созданной архитектуры, которые совсем странные.

                                                        Эта история скорее о том, как люди не хотели договариваться и каждый тянул одеяло на себя… итог в виде рваного одеяла не заставил себя ждать.
                                                          0
                                                          .net-разработчики просто должны в Angular приходить и не страдать
                                                          +22

                                                          1) Переносим имеющееся приложение с WPF, разработчики все тоже с опытом WPF
                                                          2) Берём максимально отличающуюся от MVVM технологию управления стейтом
                                                          3) ???????
                                                          4) Почему меня чуть не уволили?!


                                                          А ведь достаточно было не натягивать свою любимую сову на очередной глобус. WPF-разработчики прекрасно переезжают на связку React + MobX + Typescript, поскольку идеология организации кода и состояния практически 1 в 1 совпадают. Но Redux-сектанты будут упорно продавливать своё мнение, да.

                                                            +2
                                                            А почему бы не asp.net или ещё какой фреймворк именно на .net (C#), раз уж подавляющее большинство программистов уже используют эту технологию?
                                                              +8

                                                              Из фреймворков именно на C# сейчас для браузерной части SPA-приложений условно-пригодным является только Blazor, всё остальное использовать в продакшене нельзя в принципе никак и будет нельзя ещё года два минимум. Если вам кто-то про свою чудо-библиотеку говорит обратное, плюньте ему в глаз.


                                                              Production-ready технологии же относятся к серверсайд-рендерингу и для ряда приложений просто неприменимы.


                                                              Так что по состоянию на 2021 год C# в вебе может использоваться только на сервере.


                                                              Есть ряд решений на F# типа Fable, но это опять же слишком отличается по парадигме от WPF+MVVM.

                                                              +1
                                                              Согласен на все 100. С другой стороны, уникальный доступ к состоянию (read-write в любом месте) этот кошмар в долгосрочной перспективе :)
                                                                0
                                                                enforceActions не даст мутировать из любого места. В MobX 6 по умолчанию включен.
                                                                Если еще добавить модификаторы доступа TypeScript (private, protected), то вообще проблем не будет.
                                                                0

                                                                Совершенно с вами согласен. В моем случае мы выбирали для Vue использовать класс компоненты или новый composition API похожий на хуки React. Конечно на Typescript. Хорошо что у нас есть немного разделение на фронт и бек. Но все по умолчанию фулстеки. В итоге на фронте пошли по пути функционального кодинга. А бек у нас на PHP Laravel и там ООП, паттерны, классы… Так вот даже учитывая, что PHP не такой строгий ООП язык как C#, Java — все равно бек разработчикам крайне сложно понять и принять фунциональщину. И не все уже смогли работать фулстек. Поэтому да, если разделения нет, надо настраивать фронт под бек, никаких функций, только классы.

                                                                  0

                                                                  А почему бы не вбросить разработчикам, привыкшим к ООП, упрощающие концепты, вроде того, что функция — это такой объект с классом, имеющий всего один метод и слегка необычные особенности вызова оного метода? Или вот, так как они привыкли к паттернам, то пояснять по аналогиям с паттернами, ведь большинство из них (например Стратегия) — это реализация идей ФП в окружениях, построенных по принципам ООП.

                                                                    0
                                                                    это реализация идей ФП в окружениях, построенных по принципам ООП

                                                                    Скорее реализация в ООП идей, реализация которых в ФП не требуют каких-то специальных телодвижений. Если не говорить про стейтфулл паттерны )

                                                                      +1

                                                                      Стратегия — это инверсия контроля путём согласованной подмены группы функций. На функциях (без объектов) это разве что через свичкейс реализуется.

                                                                        0

                                                                        Во-первых, группа функций, контролируемая Стратегией, может состоять из единственной функции, что позволяет делать Стратегию тождественной просто ссылке на функцию. Таким образом это может работать и без объектов, например в C.
                                                                        Во-вторых, паттерн сам по себе не говорит, каким именно образом происходит выбор конкретной стратегии, это уже задача фабрики стратегий. А уже в фабрике можно и свитч, и словари, и много чего ещё.

                                                                          0

                                                                          А обезьяна — это такой глупый человек, потому что люди тоже бывают глупыми?


                                                                          Свичкейс нужен не для выбора стратегии, а для переключения между аспектами одной стратегии: https://redux.js.org/tutorials/fundamentals/part-3-state-actions-reducers#handling-additional-actions

                                                                            +1

                                                                            Видимо, у нас тут фундаментальное расхождение в терминах.
                                                                            Вот моё определение — https://en.wikipedia.org/wiki/Strategy_pattern — здесь нигде не говорится про какие-то аспекты одной и той же стратегии. Более того, во всех блок-схемах и примерах стратегия с точки зрения use site состоит из единственной функции.
                                                                            Где ваше определение? Эта ваша статья не содержит ни единого упоминания паттерна. Все сниппеты со свитчами — это вообще код фабрики. И даже если бы статья содержала слово "стратегия" — единственного примера из единственной библиотеки малость маловато для заключения, что паттерн всегда должен был именно как в этой библиотеке.

                                                                              0

                                                                              Я погуглил и… всё очень печально. Люди видят всего-лишь пример с одним методом и думают, что метод может быть только один. Ну, простейший пример — стратегия маршалинга, ей нужно как минимум 2 метода.

                                                                                0

                                                                                Это, кстати, и правда очень печально. Когда люди смотрят на паттерны — они не способны увидеть что-то большее, чем написано. Они не понимают, что это только приёмы, которые показаны на самых простых, вырожденных примерах и с них можно сделать что-то значительно более мощное.

                                                                                • UFO just landed and posted this here
                                                                                    0

                                                                                    А что ещё ожидать, если люди вынуждены учить паттерны, как я английский учил: The Present Perfect Continuous Tense выражает действие, начавшееся ранее и продолжающееся в момент речи или завершающееся к моменту речи. Образуется с помощью вспомогательного глагола to be в форме Present Perfect (have been, has been) и Participle I смыслового глагола — ночью разбуди тогда и ответил бы без запинки.

                                                                                    0
                                                                                    Люди видят всего-лишь пример с одним методом и думают, что метод может быть только один.

                                                                                    А вы опыт общения с другими людьми на меня не переводите. Я не говорил, что метод может быть только один. Я говорил, что он может быть только один.
                                                                                    Повторю второй раз, так как вы наверняка опять не прочитаете. Стратегия может быть с любым количеством методов, включая один метод. В случае стратегии с единственным методом, реализацию паттерна можно упростить до единственной ссылки на функцию, и в этом случае реализация не будет требовать никаких дополнительных объектов или структур, потому может быть реализована даже в процедурных языках с поддержкой ссылок на функции.

                                                                                      0
                                                                                      паттерна можно упростить до единственной ссылки на функцию

                                                                                      А в чём упрощение? Ну с точки зрения архитектуры какая разница — это функция в неймспейсе или метод в классе? То, что у класса слегка длиннее запись — лишь вкусовщина. Так в чём упрощение?

                                                                                        0
                                                                                        А в чём упрощение?

                                                                                        Очень маленькое упрощение, на самом деле. В одном случае у вас структура со ссылкой на функцию, в другом — просто ссылка на функцию (или аналог). Чтобы добраться до тела функции нужно сделать на один переход по указателю меньше (но за счёт этого по сути теряется возможность иметь более сложные каноничные стратегии из нескольких функций).

                                                                                        • UFO just landed and posted this here
                                                                      +4
                                                                      И тут я осознал, что React не дружественен ни к Java, ни к .NET разработчикам. Angular в этом случае был бы лучшим выбором из-за схожих шаблонов проектирования.


                                                                      Это как? Депенденси инжекшен он и в африке… И если они бэкендистов заставили писать фронт, а не фуллстек/фронтенд разработчиков, то ожидаемо что они будут писать говнокод без энтузиазма. Хоть на ангуляре хоть на реакте.

                                                                      И зря тут недооценивают разработчиков нет и жава. Сколько проектов видел написанных всякими жаваскрипт адептами которые раньше джеквери херачили. Зачем паттерны… это все овер, давайте без них. И быстро и кода меньше. А потом ни тестировать без магии жеста (Jest) ни поддерживать это гомно нельзя. Поэтому паттерны тут испортить ничего не могли, если естественно их применяли когда надо, а не паттерны ради паттернов.

                                                                      Я никогда не видел двух проектов React с одинаковыми зависимостями, структурой проекта и руководящими принципами.


                                                                      Ну если структуру делать feature based то она и на ангуляре разная будет.

                                                                      А вообще такое чувство что просто недооценили сложность проекта учитывая что это новый стек для разработчиков, и думали щас как в ангуляре наклепаем формочек с двусторонним байндингом и крадом и в продакшен.

                                                                      Вообще тут намешаны разные вещи не связанные с реактом от слова совсем. Билд берет время? Ну это проблема всей экосистемы ноды.

                                                                      Могу согласиться только с тем что новые хуки и контекст добавляют магию и конвенции, и действительно не все их любят, включая меня. Ну и борьба с самим собой потому что на тебе лежит ответственность выбора библиотек, а не как в ангуляре — что дали тебе в фреймворке то и юзай. Хотя и там сторонних библиотек хватает. Redux это отдельная пестня…
                                                                        +2
                                                                        Поправлю себя. Тут даже не бэкенд разработчики, а WPF. То есть возможно они всю жизнь пилили стэнд элон приложения с коннектом к базе, и тут им — держите реакт, походу разберетесь. Это риски которые менеджмент должен был учесть и оценить.
                                                                          +7
                                                                          Это как? Депенденси инжекшен он и в африке… И если они бэкендистов заставили писать фронт, а не фуллстек/фронтенд разработчиков, то ожидаемо что они будут писать говнокод без энтузиазма.

                                                                          Заставили людей с опытом десктопного фронта на MVVM писать как завещали адепты Redux. Виноватыми оказались React и разработчики.

                                                                            –2

                                                                            Обычно beckend разработка предполагает больше знаний, умений и ответственности. Поэтому не совсем понятно в чём должна быть сложность изучить и писать frontend, если стоит такая задача.

                                                                              +4
                                                                              Обычно beckend разработка предполагает больше знаний, умений и ответственности

                                                                              Как fullstack developer не могу с вами согласиться. Подавляющее большинство backend developer-ов занимаются более чем простыми вещами. Лишь немногие занимаются чем-то действительно интересным. Как например high-load-ом, сложными балансировками, большие смежными задачами.


                                                                              Подавляющее большинство backend-разработчиков:


                                                                              • знают SQL только на базовом уровне (знают про индексы, умеют писать миграции, умеют в join-ы и groupby)
                                                                              • чаще всего используют ORM, чаще всего Active Record
                                                                              • имеют отдалённое представление о системных вещах (вроде тонкостей работы сетевого стека, маршрутизации, работы с диском и т.д.)
                                                                              • не пишут никаких сложных алгоритмов. По сути практически вся задача сводится к "взять из СУДБ записи по простому запросу, преобразовать их в другую структуру данных, отправить в виде JSON на клиент" и "взять из базы данны по 10-и запросам и собрать через либу в xls отчёт"
                                                                              • пишут в рамках одной и той же парадигмы годами без изменений
                                                                              • немного умеют в docker, k8s и смежные технологии

                                                                              Разумеется из всего бывают исключения. И как только речь идёт о больших нагрузках и начинаются всякие шардирования — вот тут становится уже интересно и весьма непросто всё. Но таких контор минимум. Я думаю на 9 разработчиков уровня "гонять туда-сюда json" приходится 1 разработчик уровня серьёзного backend-а.


                                                                              И я не могу винить в этом разработчиков. Просто рынку и в самом деле сейчас не нужен сильный backend в таком количестве. А в простом виде он ужасно скучен. И совсем несложен. Я почти отошёл от backend задач, во многом из-за того что он ужасно скучный. В то время как во frontend есть потребность в очень сложных приложениях. Challenge every day. Мы уже давно перешли в "эпоху" толстых клиентов.

                                                                                –1
                                                                                У меня абсолютно противоположное мнение.
                                                                                В большинстве случаев из опытов на front могут взять студентов или же людей без профильного — риски запороть из-за этого проект минимальны.
                                                                                И картина абсолютно противоположная с backend, риски намного больше и ответственность тоже и бекенд должнен быть достаточно абстрагирован от фронденда в большинстве случаев. То что вы сталкивались с разработчиками с базовым уровнем SQL, docker, паттернов не значит что это норма и стандарт в индустрии.
                                                                                По крайней мере для серьезных проектов или энтерпрайз нужны хорошие знания языка, ООП, паттерны, многопоточность, конкурентный доступ к данным, синхронизация и тд.
                                                                                  +1
                                                                                  У меня абсолютно противоположное мнение.

                                                                                  Ну вот и ошибаетесь. Вы сами пробовали писать клиент, или так — сосед напел? Особенно какие-то сложные приложения или, тем более, игры. Я вот делал сайт для донатов — там и админка (которая позволяет ползунками настроить любую структуру), и страниця для отображения — сложные, объёмные задачи. А из сервера самое сложное — не забыть залить его вовремя, да бекапы настроить.


                                                                                  Студентов берут и на бекенд, и на фронтенд, это не показатель. На фронтенде нужно больше совмещённых знаний — тут и тех артист, и математика, и куча разного клиентского железа и по. А на сервере — вплоть до того, что ты указываешь, какой процессор нужен. Но обычно на бекенде всё просто и оно работает приблизительно одинаково. Я уж молчу о том, что бекенд тестами покрывается значительно легче. Попробуй покрыть все клиентские сценарии, которые вообще не формализируются?

                                                                                    –1
                                                                                    Не только пробывал, но и постоянно занимаюсь фулстек разработкой энтерпрайз и мид сайз решений.
                                                                                    Количество знаний необходимых для фронтенда значительно ниже, ответственность ниже, при том, что я разрабатывал и небольшие игры, и очень сложные графические компоненты. Не вижу к чему вообще этот спор и почему вас так задевает. Я же пишу, что это мнение основанное на моем опыте и я привел аргументы почему так считаю, еще очень часто разработчик бекенд с легкостью переключается на frontend, а вот обратное бывает редко и обычно требует очень серьезного изучения технологий.
                                                                                      +1
                                                                                      разработчик бекенд с легкостью переключается на frontend

                                                                                      Для полноценного переключения с backend-а на frontend потребуется, минимум года 2. И это если человек с хорошо работающей головой. И это будут мучительные 2 года.


                                                                                      обычно требует очень серьезного изучения технологий

                                                                                      Не требует. Не нужны обширные знания по многопоточности и механизмам синхронизации. Люди часто вообще таких слов не знают. Я вам напомню что большая часть backend-а это PHP, Python, Ruby, Node.js. Не нужны знания паттернов и SOLID. Потому что большая часть backend-а очень устоявшаяся вещь. Условный MVC framework на PHP имеет вполне конкретные guidelines, best practices, разделение на слои.


                                                                                      Серьёзных знаний по SQL тоже не требуется. Большую часть головняка снимает ORM. Даже виды индексов знать не надо. Даже виды транзакций большинству до одного места, т.к. народ просто тупо не пользуется транзакциями. Либо их СУБД в них не умеет :D


                                                                                      Потребуются минимальные знания про работу с файлами. На уровне: смотри вот это файловый дескриптор, вот fwrite, 1-ым аргументом дескриптор. И не забудь fclose. Всё, бери таску из jira и фигачь отчёты.


                                                                                      Знания виртуализации тоже нужны на уровне: чем docker run отличается от docker exec. ДевОпс остальное за тебя уже решил

                                                                                        0
                                                                                        Я вам напомню

                                                                                        И я напоминаю, что несмотря на GIL у Python есть полноценный мультитриденг и он успешно работает для IO операций в связке с event loop от asyncio. также можно в пару cтрочек выносить управление в отдельный процесс.

                                                                                        Серьёзных знаний по SQL тоже не требуется. Большую часть головняка снимает ORM


                                                                                        И после этого элементарный вопрос про уровни изоляции и конкурентный доступ вызывает у человека ступор. Если вы пишите для банков или даже элеметарные сайты продажи билетов, то уже необходимы хоть какие-то знания иначе получается по два человека на место, что я лично наблюдал.

                                                                                        И вот сами посудите, вы описываете, что практически никаких знаний не требуется на бекенд, но из вашего описания это уровень трейни или человека знающего программирование пол года.

                                                                                        По каждому из этих вопрсов написаны большие и толстые талмуды. Я могу себе только представить, что вы пишите простые сайты и поэтому у вас сложилось такое впечетление или же вас просто задевает и вы хвалите свое «болото». Так как entry level не вытянет бекенд, а фрондент успешно сможет именно поэтому даже из моего окружения множество перепрофилировалось из других профессий на фронтенд или QA automation, а на бекенд никого.
                                                                                          0
                                                                                          или же вас просто задевает и вы хвалите свое «болото».

                                                                                          Любопытно, что это у вас клиент пишут студенты и вы не видели хороших фрондэндщиков, а болото — у нас.

                                                                                            0
                                                                                            Ну с чего такие выводы? (вопрос риторический отвечать не стоит)
                                                                                            Я ничего про комманду не писал вообще, а вы фантазируйте. Я лишь выразил свое субьектинвное мнение основанное на опыте. Для меня ваши аргументы звучат все-равно что вы сейчас будете доказывать, что работа секретаря или QA сложней чем у программиста. Я понимаю, что она сложная и важная, но она проще. Учитесь не воспринимать в штыки другое мнение и слышать.
                                                                                              0

                                                                                              Ну у вас ведь вообще нету аргументов кроме "Бекенд это сложно". Вот вы говорите, что уходят с бекенда на фронтенд. Да, я вот первые 5 лет был бекендщиком и понял, что это — скучно, потому постарался переметнуться во фронтенд, ведь тут есть разные новые задачи, а в бекенде хотя я и не дошёл до верха — там всё то же самое. Ну да, выучил дополнительно пару технологий, но опять же просто фигачешь по шаблонам.


                                                                                              Ваша аналогия — глупая и я объясню почему.


                                                                                              Видите ли, бекенд — это ремесло, как рабочий, который клепает одинаковые гайки на заводе 30 лет. Да, это тяжело, это утомительно, этому надо научиться, но это не сложно.


                                                                                              Фронтенд же ж — скорее инженерия, когда у тебя нету готового решения. Тут реально появляются сложные новые задачи, но бекендищу и джун-фрондэндщикам этого не понять.


                                                                                              Бекенд — это словно зазубрить огромный талмуд, это реально тяжело. Фронденд — это словно такой талмуд написать. Да, это легче чисто психологически, ведь меньше рутины, больше творчества, но требует сильно больше интеллектуальной работы.


                                                                                              Вам стоит учиться слышать другие мнения кроме своего и поменьше волноваться из-за того, что не смогли осилить переход в более тяжёлую область.

                                                                                                +1
                                                                                                Бекенд — это словно зазубрить огромный талмуд, это реально тяжело. Фронденд — это словно такой талмуд написать

                                                                                                Хорошая аналогия! Надо запомнить. Действительно, когда пишешь сложный SPA чувствуешь что пробиваешь головой стену. Никаких готовых к использованию решений. И большой спектр задач.


                                                                                                С одной стороны почти никогда не бывает скучно. С другой стороны вечный brain-storm.

                                                                                                  –1
                                                                                                  Я вам искренне завидую, что у вас еще задачи вызывают brain-storm. У меня обычно такого brain-stormа нет по той причине, что я знаю как это реализовать когда заказчик только пытается в первых строчках обьяснить чего он хочет на первом слайде.
                                                                                                  Единственное что в этой ситуации может быть интересно это архитектура приложений.
                                                                                                    +1
                                                                                                    что я знаю как это реализовать когда заказчик

                                                                                                    Ну ведь мы вам об этом как раз и говорим. Бекенд задачи — именно такие. Потому бекенд и неинтересный.

                                                                                                  0

                                                                                                  Это всё зависит от подхода. Если на каждый эндпоинт копипастить типовой код, то это мало чем отличается от копипасты формочек на фронте. Я, например, делал такой бэкенд, где:


                                                                                                  1. Предметная область описывается простым конфигом, по которому автоматически поднимается БД.
                                                                                                  2. Есть всего несколько эндпоинтов, каждый из которых может работать с любой моделью по единым правилам.
                                                                                                  3. Fetch Plan определяется текущими потребностями клиента, а не хардкодится.
                                                                                                  4. Код модели шарится с фронтом — её не надо описывать дважды.
                                                                                                  5. Данные в реальном времени обновляются через сокеты.
                                                                                                  6. Подсписка на обновления и отписка происходят автоматически.
                                                                                                  7. Всё это шардится и реплицируется.

                                                                                                  Не назвал бы это скучным закручиванием гаек. Не бывает скучный областей деятельности. Бывают скучные люди.

                                                                                                    0
                                                                                                    Вы просто не умеете читать и делаете противоположные от написанного умозаключения.

                                                                                                    Я десятый раз пишу, что это основано на моем опыте и он субьктивный.

                                                                                                    А вас настолько задевает и трясет, что вы мне приписываете и неумение во фронтенд (хотя это самое легкое что я вообще делал).
                                                                                                    И то что нас много студентов в комманде, хотя их нет вообще.

                                                                                                    Учитесь читать и слушать других.
                                                                                                    Я не отрицаю что у вас интересные и сложные для вас задачи.
                                                                                                      +2
                                                                                                      Я десятый раз пишу, что это основано на моем опыте и он субьктивный.

                                                                                                      Ваш опыт очень плохо отражает объективную реальность. Но читать почему-то не умею я. Интересно.

                                                                                                        –1

                                                                                                        А где тут в треде объективная реальность? Аргументы уровня "скучно", "интересно", "есть вызов" — это субъективизм чистой воды.

                                                                                                        +1

                                                                                                        Видимо то, что вы считали очень сложным и интересным для остальных программистов оказывается скучной рутиной и именно потому вы тут сопли развели и хнычите.

                                                                                                  0
                                                                                                  у Python есть полноценный мультитриденг

                                                                                                  Да и в node-js можно с потоками писать. But why? Это точно не входит в перечень необходимых знаний для python\nodejs backend разработчиков middle (и возможно senior) уровней. А случае PHP вообще граничит с безумием и ненормальным программированием.


                                                                                                  но из вашего описания это уровень трейни или человека знающего программирование пол года.

                                                                                                  Не, никаких ни пол-года. Но года три в среднем достаточно. Для фронта мне кажется около 8-ми нужно.


                                                                                                  что вы пишите простые сайты

                                                                                                  Не я пишу. А backend программисты пишут. И да. Вы попали в самую точку. Большинство backend программистов пишут простые сайты. Вот прямо в десяточку. Не знаю как от вас эта простая истина ускользала все эти годы.


                                                                                                  а фрондент успешно сможет

                                                                                                  Не сможет. Не знаю таких случаев. Обратно — легко. Я провёл много собеседований.


                                                                                                  QA automation

                                                                                                  Вам не смешно сравнивать QA-automation c frontend? Вы выше писали про то, что вы full-stack. Мне кажется вы лукавите. Складывается впечатление что вы имеете очень отдалённое представление о современном frontend-е.

                                                                                                    0
                                                                                                    Складывается впечатление

                                                                                                    Складывается ложное впечатление из-за того что вас задевает что кто-то считает что фрондент проще, а это ваша любимая сфера деятельности.

                                                                                                    Но я уже десятые раз пишу, что спор не имеет смысла, для меня лично и для тех с кем я общаюсь он очень простой.
                                                                                                    Кстати, если у вас вызывает именно сложность в изучении всех фреймворков, то это опять же с лихвой заменяется изучением базовых подходов и концепций. После этого любой новый фреймворк становится предельно ясным после прочтения документации, вы просто будете моментально знать как работает на фоне. Такие знания более полезны чем знания условного Vue.
                                                                                                      0

                                                                                                      Вы правда думаете что я не понимаю как устроен React и Vue? :) Сложность вызывает не изучение framework-ов, а умение с ними сварить кашу. В подавляющем большинстве случаев люди не могут выстроить разумную архитектуру. Ни разу не слышал о таких проблемах в популярных PHP-фреймворках. С ними вы начинаете приложение с того, что архитектура уже готова и она разумна. Главное придерживаться нескольких концептов.

                                                                                                +1
                                                                                                Не только пробывал, но и постоянно занимаюсь фулстек разработкой энтерпрайз и мид сайз решений.

                                                                                                Ну тогда должны понимать, что бекенд разработка значительно легче фронтенд. Туда легче переключится, да и фрондендщики легко туда переходят в отличии от обратной. Не понимаю, почему у вас так горит с этого.

                                                                                                  0
                                                                                                  Я такого не встречал ни разу.
                                                                                                  и множество вайтишников именно на фронтенд, будем считать это исключительно совпадением.
                                                                                                    0

                                                                                                    Ну да, ну да. Ведь так круто писать фронтенд на пхп и питоне. А на ДжаваСкрипт люди начали идти только когда он тоже осерверился


                                                                                                    Я рад, что для вас это аргумент, что бекенд значительно легче.

                                                                                                      0
                                                                                                      JavaScript начали идти так как это один из самых простых языков программирования с низким порогом вхождения (ничего плохого в этом нет мне он тоже нравится).
                                                                                                        0

                                                                                                        Вот только JS появился в один год с ПХП и Питоном, а начали идти только когда стал популярный серверный. Причинно-следственные связи улавливаем?

                                                                                                          0
                                                                                                          Я вас удивлю и дам исторический урок, но JavaScript и на фронтенде стал популярным относительно недавно с выходом jQuery. А набег вайтишников уже попер с появлением фреймворков новой волны и это не связано с Node.JS так как при изучении JavaScript Node.JS учат в самую последнюю очередь.
                                                                                                            +1

                                                                                                            Я вас удивлю, но эту историю я видел, писал и делал сам, а не прочитал в интернетике.

                                                                                                              0
                                                                                                              Я вас удивлю и дам исторический урок, но JavaScript и на фронтенде стал популярным относительно недавно с выходом jQuery.

                                                                                                              На вашем месте я бы постеснялся в 2021 году имплицировать, что выход jQuery был "относительно недавно". Потому что в 2021 году выход jQuery относительно зарождения интернета был практически настолько же "недавно", что и относительно текущего момента.

                                                                                                                0
                                                                                                                Не вижу в чем суть, для меня это недавно.
                                                                                                        0
                                                                                                        и множество вайтишников именно на фронтенд, будем считать это исключительно совпадением.

                                                                                                        Собственно дальше позиции верстальщиков из вайтишников мало кто уходит. А это не программирование.

                                                                                                          0
                                                                                                          Успешно справляются с React и Vue. Angular идет сложней обычно, но там нужно просто уже хоть два паттерна знать. Хотя меня это меня и немного удивляет, почему он вообще может казаться сложней.
                                                                                                            +2
                                                                                                            Успешно справляются с React и Vue.

                                                                                                            C React успешно справляется процентов 10% из тех кто на нём пишет. Оставшиеся 90% только думают, что что-то в нём понимают. Я проводил много собеседований и знаю о чём говорю.


                                                                                                            Код этих 90% = write only. Именно после таких вот "справившихся" мы читаем очередной longread о том "как я внедрил в проект react и меня чуть не уволили". Концепции которые лежат в основе вменяемого React кода слишком сложны для подавляющего большинства разработчиков. Включая backend разумеется.


                                                                                                            Большинство "react-разработчиков" даже документации не читали. SPA написанные ими настолько кривые что при росте бизнеса приходится всё выкидывать и начинать писать с нуля, уже руками тех людей, кто понимает как это всё работает.


                                                                                                            С Vue точно такая же петрушка. 99% "Vue разработчиков" (мне даже сам термин %framework%-разработчик противен) даже не знают как работает observable. О результатах я думаю вы догадываетесь


                                                                                                            Вот только в случае с Angular есть какие-то надежды. Костные framework-и, где за вас уже всё решили — они пригодны для начинающих. Меньше шансов выстрельнуть в ногу = хорошо. К тому же он ближе к типичным backend концептам.

                                                                                                              0
                                                                                                              C React успешно справляется процентов 10% из тех кто на нём пишет. Оставшиеся 90% только думают, что что-то в нём понимают. Я проводил много собеседований и знаю о чём говорю.

                                                                                                              Я думаю вы преувеличиваете, мой опыт говорит что от силы 5%. Истина где-то посередине =)
                                                                                                                0
                                                                                                                Оставшиеся 90% только думают, что что-то в нём понимают.


                                                                                                                Про что я и писал выше. Ситуация на рынка такова, что такое качество допустимо и поэтому много вайтишников, и поэтому достаточно даже 5% чтоб начать. Но вот опять же, выбросить через год cайт, это не тоже самое, что выбрость core функционал.

                                                                                                                  +1
                                                                                                                  Ситуация на рынка такова, что такое качество допустимо

                                                                                                                  Т.е. то что на рынке есть конторы которые готовы нанимать абы кого, чтобы писать абы что, и потом это выкидывать через год… Заставляет вас думать что frontend простой? :)


                                                                                                                  Desktop разработка переехала в web. А она всегда была довольно сложной и разнообразной. И теперь ею занимаются front-ы. Это подразумевает довольно сложный UI. На рынке просто элементарно не хватает хороших специалистов. В итоге людям приходится довольствоваться тем, что есть. Получаются кривые тормозящие решения. Это то самое следствие того, что вам тут все пишут. То что фронтенд стал сложным, а разработчиков которые в него умеют — слишком мало.

                                                                                                    +3
                                                                                                    В большинстве случаев из опытов на front могут взять студентов или же людей без профильного — риски запороть из-за этого проект минимальны.

                                                                                                    Возможно мой опыт нерелевантен, но я последние годы работал над проектами, куда не только студентов не возьмёшь, а вообще разработчиков уровня ниже senior-а лучше не брать. Да и senior-у вникать пару месяцев, прежде чем он выйдет на окупаемость. Про студентов я вообще молчу. Они действительно не смогут запороть проект, т.к. я не могу дать им вообще никаких задач. Признаюсь я вообще не знаю как можно выстроить архитектуру большого SPA так, чтобы junior мог приносить больше пользы, чем вреда. Наверное я дурак. А может web свернул не туда. Но правда — всё слишком сложно.


                                                                                                    А вот на backend-е я вполне себе представляю задачи под junior-а. Например — напиши endpoint который по ID товара делает запрос в базу, трансформирует результат в такую-то форму и передаёт на клиент в таком-то виде. Сделай по аналогии с вот этим местом. И покрой тестом. Пример теста вот здесь. Там почти копипаста.


                                                                                                    риски намного больше и ответственность

                                                                                                    ??? Почему выше риски? XSS сопоставимы с SQL инъекциями по уровню наносимого ущерба. Это если вы про безопасность. А если про ущерб бизнесу из-за багов — то не так важно где баг сломал функциональность на клиенте или на сервере. Если что-то не работает, то бизнес теряет деньги.


                                                                                                    многопоточность

                                                                                                    Огромная часть бакенда это PHP, python, ruby. О какой многопоточности вы говорите?


                                                                                                    для серьезных проектов

                                                                                                    Коих абсолютное меньшинство


                                                                                                    энтерпрайз

                                                                                                    Вот только сказки про сложный ынтерпрайз не надо рассказывать. Все мы знаем насколько он чаще всего ущербен и примитивен. И как люди его избегают, чтобы не деградировать. Понятно, что бывает и по-другому, но как правило ынтерпрайз = дно.


                                                                                                    конкурентный доступ к данным, синхронизация

                                                                                                    В подавляющем большинстве случаев бакенд-разработчик может даже не знать таких слов и прекрасно справляться со своими должностными обязанностями. Come on, зачем вам это в связке "запрос в базу — отправить json на клиент".


                                                                                                    ООП, паттерны

                                                                                                    Не нужно всего этого знать. Для большинства backend проектов уже есть готовые матёрые framework-и где всё за вас продумано. Будь это Symphony, или Play или Django. Открыл документацию, почитал правила нейминга и как делить код на слои, посмотрел на примеры кода, посмотрел как другие ребята пишут в проекте — и понеслась.


                                                                                                    Пожалуйста не путайте сложный замороченный backend, которого исчезающе мало, и обыкновенную монотонную работу по перекладыванию json-а.


                                                                                                    В противовес этому на фронте есть множество замороченных паттернов и даже очень опытные разработчики не могут придти к тому как это всё правильно писать и связывать. На рынке frontend-а хаос, джунгли, полная анархия. Нет никаких best practice. Любая информация, которая сейчас рассматривается, как незыблемая истина, завтра считается мусором. Особенно если речь идёт про React. В случае React каждая контора пишет какой-нибудь свой универсальный велосипед, собирая его как конструктор, на лету изобретая его части. Это правда действительно очень сложно.

                                                                                                      0
                                                                                                      То что вы описываете это абсолютная деградация отрасли. Энтерпрайз это где основные деньги, а избегают этого просто из-за того что нужно именно что-то знать)
                                                                                                      А зачем если можно не зная ничего (судя по вашем описанию) шлепать простые сайты и получать деньги. Я не осуждаю, просто вы должны понимать что есть разные проекты, мне, например, попадались всегда громадные и сложные.
                                                                                                        +1
                                                                                                        То что вы описываете это абсолютная деградация отрасли

                                                                                                        Для того, чтобы деградировать нужно, чтобы было чему деградировать. Серверная разработка, как более простая быстро была строго формализована и лучшие инженерные решения были давно открыты и посвеместно приняты. Клиентская разработка, увы, порядком сложнее и потому сама по себе теория для неё до сих пор продолжает расти.

                                                                                                          +3
                                                                                                          Энтерпрайз это где основные деньги, а избегают этого просто из-за того что нужно именно что-то знать)

                                                                                                          O_o. WAT? Что-то знать для ынтерпрайза? Зачем?


                                                                                                          Я не осуждаю, просто вы должны понимать что есть разные проекты, мне, например, попадались всегда громадные и сложные.

                                                                                                          Громадный != сложный. Громадный почти всегда = говнокод + legacy + кривая архитектура. Громадный = много команд разработчиков = большое количество бюрократии, дурака-валяния, подковёрных игр, идиотических поступков ради премий. Громадный обычно = устаревшие технологии, огромный технический долг, очень низкий уровень разработчиков.


                                                                                                          В ынтерпрайзе платят больше в первую очередь "за вредность". Человек приходя на такой проект знает что будет больно. Что его знания и опыт помножат на ноль и заставят чинить кривые велосипеды путём расставления ещё большего количества кривых костылей. В ынтерпрайзе лучше как раз не знать. Тогда говнокодить будет не больно.


                                                                                                          Один из моих бывших шефов сказал гениальную фразу: программисты приходят в банки чтобы умирать (как специалисты). Один мой знакомый программист из банка пару лет назад хвастался что смог уговорить руководство и внедрить git. До этого у них СУВ вообще не было.


                                                                                                          Ну и нет тут никакой деградации отрасли. Всегда так было.

                                                                                                            0
                                                                                                            кривая архитектура

                                                                                                            Это совсем не так, если бы так было, то их бы не могли поддерживать годами, а это происходит.

                                                                                                            Обычно архитектура таких приложений всегда продумана и отточена, легко покрывается тестами, легко масштабируется.
                                                                                                            Поэтому автобусы ездят, самолеты летают, банкоматы выдают деньги и интернеты ваши вообще бегают.

                                                                                                            Но не суть, я представляю, что бывает иначе и ваш знакомый попал на такой случай.
                                                                                                              +1
                                                                                                              то их бы не могли поддерживать годами, а это происходит.

                                                                                                              вот вам моя любимая паста про Oracle:


                                                                                                              long read

                                                                                                              Oracle Database 12.2.
                                                                                                              It is close to 25 million lines of C code.


                                                                                                              What an unimaginable horror! You can't change a single line of code in the product without breaking 1000s of existing tests. Generations of programmers have worked on that code under difficult deadlines and filled the code with all kinds of crap.


                                                                                                              Very complex pieces of logic, memory management, context switching, etc. are all held together with thousands of flags. The whole code is ridden with mysterious macros that one cannot decipher without picking a notebook and expanding relevant pats of the macros by hand. It can take a day to two days to really understand what a macro does.


                                                                                                              Sometimes one needs to understand the values and the effects of 20 different flag to predict how the code would behave in different situations. Sometimes 100s too! I am not exaggerating.


                                                                                                              The only reason why this product is still surviving and still works is due to literally millions of tests!


                                                                                                              Here is how the life of an Oracle Database developer is:


                                                                                                              • Start working on a new bug.


                                                                                                              • Spend two weeks trying to understand the 20 different flags that interact in mysterious ways to cause this bag.


                                                                                                              • Add one more flag to handle the new special scenario. Add a few more lines of code that checks this flag and works around the problematic situation and avoids the bug.


                                                                                                              • Submit the changes to a test farm consisting of about 100 to 200 servers that would compile the code, build a new Oracle DB, and run the millions of tests in a distributed fashion.


                                                                                                              • Go home. Come the next day and work on something else. The tests can take 20 hours to 30 hours to complete.


                                                                                                              • Go home. Come the next day and check your farm test results. On a good day, there would be about 100 failing tests. On a bad day, there would be about 1000 failing tests. Pick some of these tests randomly and try to understand what went wrong with your assumptions. Maybe there are some 10 more flags to consider to truly understand the nature of the bug.


                                                                                                              • Add a few more flags in an attempt to fix the issue. Submit the changes again for testing. Wait another 20 to 30 hours.


                                                                                                              • Rinse and repeat for another two weeks until you get the mysterious incantation of the combination of flags right.


                                                                                                              • Finally one fine day you would succeed with 0 tests failing.


                                                                                                              • Add a hundred more tests for your new change to ensure that the next developer who has the misfortune of touching this new piece of code never ends up breaking your fix.


                                                                                                              • Submit the work for one final round of testing. Then submit it for review. The review itself may take another 2 weeks to 2 months. So now move on to the next bug to work on.


                                                                                                              • After 2 weeks to 2 months, when everything is complete, the code would be finally merged into the main branch.



                                                                                                              The above is a non-exaggerated description of the life of a programmer in Oracle fixing a bug. Now imagine what horror it is going to be to develop a new feature. It takes 6 months to a year (sometimes two years!) to develop a single small feature (say something like adding a new mode of authentication like support for AD authentication).


                                                                                                              The fact that this product even works is nothing short of a miracle!


                                                                                                              I don't work for Oracle anymore. Will never work for Oracle again!


                                                                                                              source


                                                                                                              И это Oracle. В конторах попроще всё ГОРАЗДО хуже. Вы 1-ый программист на всём моём жизненном пути, кто вообще отзывается об ынтерпрайзе в позитивном ключе.

                                                                                                                0
                                                                                                                Вы просто гараздо младше меня, поэтому и первый для вас.
                                                                                                                  0
                                                                                                                  Вы 1-ый программист на всём моём жизненном пути, кто вообще отзывается об ынтерпрайзе в позитивном ключе.

                                                                                                                  Если серьезно, ынтерпрайз бывает разный (даже в банках). Есть ынтерпрайз по типу того, что у вас в лонгриде про оракл. У него простые признаки:
                                                                                                                  1) он приносит деньги и продолжает приносить деньги
                                                                                                                  2) он древний, как говно мамонта, и продолжает быть таковым
                                                                                                                  Такой энтерпрайз практически всегда скатывается к тому, что описано в лонгриде — к стройной, и устоявшейся веками системе костылей, велосипедов, и подпорок. Которую невозможно переписать, а попытки поддерживать — вызывают рак мозга.


                                                                                                                  Но есть и другой энтерпрайз: главным образом то, что денег не приносит (или приносит немного относительно вышенаписанного). Вот там всё намного лучше, как правило — без постоянного давления бизнеса там всё чуть свободнее, программисты не всегда работают на дедлайны (а иногда на качество), да и вообще продукт как правило можно переписывать, не опасаясь быть уволенным.


                                                                                                                  Ergo, если работать в энтерпрайзе — главное, не работать на прибыльных и сверхприбыльных проектах. А вот на загибающихся, внутренних, или только же зарождающихся — вполне.

                                                                                                            –2
                                                                                                            Признаюсь я вообще не знаю как можно выстроить архитектуру большого SPA так, чтобы junior мог приносить больше пользы, чем вреда. Наверное я дурак.

                                                                                                            Да нет, вы просто $mol не пробовали, поэтому и не знаете. Тут всё просто:


                                                                                                            1. Инкапсуляция. Не сокрытие, а именно инкапсуляция, когда ты берёшь компонент и просто его используешь без приседаний вокруг импортов, сторов, DI и тп.
                                                                                                            2. Минимум абстракций. Простые абстракции. Классы, реактивные свойства, контекст окружения — этого уже достаточно.
                                                                                                            3. Разделение на слои. Модель отдельно, логика отдельно, композиция компонент отдельно, оформление отдельно. А не вперемешку, как в Реакте.

                                                                                                            А вот на backend-е я вполне себе представляю задачи под junior-а. Например — напиши endpoint который по ID товара делает запрос в базу, трансформирует результат в такую-то форму и передаёт на клиент в таком-то виде. Сделай по аналогии с вот этим местом. И покрой тестом. Пример теста вот здесь. Там почти копипаста.

                                                                                                            На фронте будут такие задачи по нарастающей:


                                                                                                            • Поправь стили у такой-то группы компонент, чтобы выглядело так-то. Квалификация: стилизатор.
                                                                                                            • Собери такой-то компонент из вот этих вот, чтобы проходил такие-то тесты. Квалификация: компоновщик.
                                                                                                            • Вот тебе пример использования компонента, реализуй его, чтобы работал. И тесты не забудь. Квалификация: реализатор.
                                                                                                            • Вот тебе макет, реализуй страничку, чтобы было похоже. Квалификация: разработчик.
                                                                                                            • Нужна какая-то штука, чтобы упростить работу с такими-то типами задач. Квалификация: проектировщик.

                                                                                                            При этом каждый может делегировать соответствующую часть своей работы фронтендеру меньшей квалификации и, соответственно, помогать ему расти.

                                                                                                              0
                                                                                                              У вас есть хоть одна ссылка где бы кто либо из профессионалов попробывал вашу библиотеку и дал сравнение или отзыв? Не с целью задеть, а реально интересно.
                                                                                                                0

                                                                                                                Сам уже 4 года жду какую-нибудь разгромную статью про то, как в $mol всё плохо, но пока глухо.

                                                                                                                  +2

                                                                                                                  Вот тут есть неплохая подборка постов на эту тему: https://habr.com/ru/users/vintage/posts/

                                                                                                                    0

                                                                                                                    Это мои статьи, а речь шла о неангажированном анализе.

                                                                                                                      +1

                                                                                                                      Я знаю, что это ваши статьи. Однако, все недостатки $mol винды прямо из них, достаточно внимательно прочитать…

                                                                                                                        0

                                                                                                                        То что вы считаете недостатками не обязательно таковым и является.

                                                                                                              0
                                                                                                              Открыл документацию, почитал правила нейминга и как делить код на слои, посмотрел на примеры кода

                                                                                                              Вот в случае примеров кода Symfony в разделах про СУБД сплошные антипаттерны, потому что показывают как из фреймворка достучаться до слоя данных, а не как его организовывать.

                                                                                                                0
                                                                                                                антипаттерны

                                                                                                                антипаттерны тоже паттерны ;)

                                                                                                                  0

                                                                                                                  Формально, да. На практике это "как надо делать" и "как не стоит делать без чёткого понимания плюсов и минусов". А так 90% проектов на Symfony с Doctrine будут содержать анемичные модели из геттеров и сеттеров потому что так в документации и даже средства кодогенерации для этого есть

                                                                                                                    0
                                                                                                                    А как должно быть по-вашему? Желательно конкретные названия паттернов или ссылки.
                                                                                                                      0

                                                                                                                      Умная модель, абстрагирующая остальные слои от деталей хранения, а не размазывающая их по всей кодовой базе.

                                                                                                                        0
                                                                                                                        Вы про ActiveRecord что ли? Этот паттерн по-вашему лучше, чем DataMapper?
                                                                                                                        а не размазывающая их по всей кодовой базе
                                                                                                                        Где Вы «размазывание» увидели? Есть модель, есть репозиторий. Что не так?
                                                                                                                      • UFO just landed and posted this here
                                                                                                                          0

                                                                                                                          Речь тут прежде всего о хранении в памяти — составе и типах полей.

                                                                                                                          0

                                                                                                                          Мухи (модель) отдельно, котлеты (хранение) отдельно

                                                                                                                          0

                                                                                                                          Сущности Доктрины моделируют сущности предметной области, а там, обычно, нет операций типа "установить статус заказа в "Доставлен" или "Отменён"". Order::setStatus(Order::STATUS_CANCELED) отклоняется от предметной области и нарушает инкапсуляцию модели. Просто Order::cancel();


                                                                                                                          https://ocramius.github.io/doctrine-best-practices/

                                                                                                                            0

                                                                                                                            На самом деле в предметных областях очень много именно "статусов", а не вязанки cancel/reopen/reorder/resign и тд. Ибо многие переходы обратимы, а многие пропускаемы. В итоге на 10 статусов может быть до сотни переходов. И отдельно описывать каждый из них — это удавиться можно. Тут гораздо лучше работает разделение на "требования для перехода в нужный статус" (например, товар не отгружен, счёт оплачен) и "намерение перейти в нужный статус" (например, хочу, чтобы заказ был отменён).

                                                                                                                              0

                                                                                                                              Одно другому не мешает, метод cancel может быть примерно таким:


                                                                                                                              public function cancel(): void
                                                                                                                              {
                                                                                                                                if ($this->canStatusBeChangedTo(self::STATUS_CANCEL) {
                                                                                                                                  $this->changeStatusTo(self::STATUS_CANCEL);
                                                                                                                                } else {
                                                                                                                                  throw new \DomainException("Order can't be canceled"); 
                                                                                                                                }
                                                                                                                              }

                                                                                                                              Или вы что-то другое имели в виду?

                                                                                                                                0

                                                                                                                                И какой смысл заводить 100500 методов с одинаковым содержимым, отличающимися лишь константами?

                                                                                                                                  0

                                                                                                                                  Для инкапсуляции конкретной реализации, и для того, чтобы все места, где Order может быть отменён, делали это одинаковым (правильным) образом, а не как придётся.

                                                                                                                                    0

                                                                                                                                    Отмена из разных состояний — это совсем разные процессы. Единственное, что их объединяет, — это конечное состояние.

                                                                                                                                      +2

                                                                                                                                      Не "отмена из разных состояний" — а "отмена из разных мест в коде". Отменяться заказ может как прямой командой пользователя, так и реакцией на событие или вообще по истечению времени — и все эти случаи лучше привести к единому order->cancel(), чем иметь повсюду разные случаи прямых вызовов order->setStatus(CANCELLED), которые неизбежно в итоге разойдутся и будут выглядеть по-разному и содержать разные баги.

                                                                                                                                        0

                                                                                                                                        order->cancel() ничем принципиально не отличается от order->setStatus(CANCELLED) кроме возможности во втором случае иметь обобщённую логику, вместо копипасты.

                                                                                                                                          0

                                                                                                                                          Почему из order->cancel() хоть как-то следует копипаста?

                                                                                                                                            0
                                                                                                                                              0

                                                                                                                                              Я вас не понимаю. И что? Вы предлагаете не писать код, который должен исполнятся при переходе в статус CANCELLED?


                                                                                                                                              "Если юзер использует наше приложение не так, как задумал программист — он сам дурак", правильно?

                                                                                                                                                0

                                                                                                                                                Я предлагаю писать обобщённый код, а не копипастить типовой код на каждую проводку. Ну, подумайте над системой, где админ может накликивать бизнес процесс. Это предел обобщённости. Там не может быть никаких методов order(), а энам со статусами вообще в базе хранится. Даже если не нужна такая гибкость, проект куда проще развивать, если это все не хардкодить.

                                                                                                                                            +1
                                                                                                                                            order->cancel() ничем принципиально не отличается от order->setStatus(CANCELLED)

                                                                                                                                            Ну как это не отличается? Допустим, в вашей системе при отмене ордера должно так же отменяться всё планирование поставок, логистики, складских операций. Допустим, для упрощения, что всё напрямую не связанное с ордером выносится в другие домены через события. Тогда в псевдокоде:
                                                                                                                                            cancel()


                                                                                                                                            fun cancel():
                                                                                                                                                if not this->canBeCancelled() then:
                                                                                                                                                    throw UpdateError('Order can not be cancelled')
                                                                                                                                                end
                                                                                                                                                this.status := OrderStatus.Cancelled
                                                                                                                                                storage->flush(this)
                                                                                                                                                evenBus->fireEvent(OrderCancelled(this))
                                                                                                                                            end

                                                                                                                                            А в случае с setStatus будет примерно вот так:


                                                                                                                                            fun setStatus(OrderStatus value):
                                                                                                                                                eventType:= Nil
                                                                                                                                                if value == OrderStatus.Draft then:
                                                                                                                                                    ...
                                                                                                                                                elif value == OrderStatus.New then:
                                                                                                                                                    ...
                                                                                                                                                elif value == OrderStatus.InProcessing then:
                                                                                                                                                    ...
                                                                                                                                                <!--думаю, так уже достаточно понятно-->
                                                                                                                                                elif value == OrderStatus.Cancelled then:
                                                                                                                                                    if not this->canBeCancelled() then:
                                                                                                                                                        throw UpdateError(
                                                                                                                                                            'Order can not be cancelled'
                                                                                                                                                        )
                                                                                                                                                    end
                                                                                                                                                    eventType := OrderCancelled::Ref
                                                                                                                                                else
                                                                                                                                                    throw UnknownOrderStatus(value)
                                                                                                                                                end
                                                                                                                                                this.status := value
                                                                                                                                                storage->flush(this)
                                                                                                                                                eventBus->fire(eventType->create(this))
                                                                                                                                            end

                                                                                                                                            При этом в первом варианте если типы можно абстрагировать, то может быть вообще примерно так:


                                                                                                                                            fun cancel():
                                                                                                                                                this->runStatusChange(
                                                                                                                                                    this.canBeCancelled::Ref,
                                                                                                                                                    OrderStatus.Cancelled,
                                                                                                                                                    OrderCancelledEvent::Ref
                                                                                                                                                )
                                                                                                                                            end

                                                                                                                                            А вот во втором случае от if ... elif ... elif ... else (или аналогичного switch) избавиться уже далеко не так просто.

                                                                                                                                              +1

                                                                                                                                              Ну вот вы в конце и пришли к обобщённой функции runStatusChange, параметризированной статусом. Теперь вы можете сделать ещё один шаг:


                                                                                                                                              fun setStatus(OrderStatus status):
                                                                                                                                                  this->runStatusChange(
                                                                                                                                                      status.Allow,
                                                                                                                                                      status,
                                                                                                                                                      status.Event,
                                                                                                                                                  )
                                                                                                                                              end

                                                                                                                                              А потом ещё один, и убрать этот runStatusChange совсем.


                                                                                                                                              А от ветвлений вы никак не избавитесь в любом случае, ибо они приходят из предметной области. В лучшем случае удастся упаковать это в стратегии, получаемые на основе текущего статуса и целевого.

                                                                                                                                                0
                                                                                                                                                status.Allow, status.Event

                                                                                                                                                Так детали реализации протекут к пользователю. Если паковать в стратегии, то можно получить что-то лучшее чем оба варианта выше, но как правило система не настолько гибкая, чтобы оправдать внедрение подобных стратегий сходу.

                                                                                                                                                • UFO just landed and posted this here
                                                                                                                                                    0

                                                                                                                                                    Я не понимаю, на что именно вы возразили, честно говоря.
                                                                                                                                                    Обобщённый объект — это который из двух? Order? Или OrderStatus? Если второе, то как раз плохо то, что стратегия является частью статуса — а это значит, что мой домен ей, вообще-то, не может доверять, если все возможные стратегии не известны заранее и сам объект конструирует кто-то за пределами домена.

                                                                                                                    +1

                                                                                                                    Что-то я пропустил главную вашу фразу. Вот эту:


                                                                                                                    То что вы сталкивались с разработчиками с базовым уровнем SQL, docker, паттернов не значит что это норма и стандарт в индустрии.

                                                                                                                    Причём тут разработчики? Я вам про рынок говорю. Огромный процент backend разработчиков пишут весьма примитивные backend-ы для весьма примитивных сервисов. Ну come on. Большая часть бакенда в мире это просто 1 mysql/postgresql база, какой-нибудь Symphony или Django, и 50-200 endpoint-ов, из которых 90% это перекладывание JSON-а.


                                                                                                                    Я как раз сталкивался с крутыми backend разработчиками. Например я сейчас работаю в конторе, которая пишет отказоустойчивый high-load backend в облаке, на микросервисах, с шардированием, нестандартными решениями, и прочем фарше. И да, в FP парадигме.


                                                                                                                    Просто я прекрасно понимаю, что это даже близко не норма. Это "крутой уровень", и крутые интересные задачи. Открывая на бирже труда "backend developer" вы вместо этого скорее увидите "Middle/Senior PHP developer. Laravel min. 3 years". Получив offer будете клепать одинаковые web-проекты под копирку. Даже тесты, вероятно писать не будете, ибо финансово неоправданно. Весь code — write only.

                                                                                                                      0
                                                                                                                      Это "крутой уровень", и крутые интересные задачи

                                                                                                                      И этот уровень всё-равно достичь легче, чем уровень клиентщика в сложной игре. По сути там несколько принципиальных концепций выучить надо, да и по библиотекам уже всё более-менее устоялось, сделал такой сервис один раз — остальные разы уже по накатанной

                                                                                                                        0
                                                                                                                        Вы когда будете расти, то и вокруг вас будут появлятся более профессиональные люди и вы увидите, что мир не заканчивается только Перекидыванием JSON-а. Мне например не попаются проекты где нужно просто пару JSON-а перебросить.
                                                                                                                          0

                                                                                                                          Вы вероятно невнимательно меня читаете. В моей текущей конторе как раз и работают весьма толковые backend программисты, которые пишут сложный high-load backend. И у нас на кухне разговоры про шардирование, property based testing, алгебраические эффекты, FP, всякие тонкости реализаций DI и пр.


                                                                                                                          Но я прекрасно понимаю насколько это редкий case. Типовой backend = перебрасывание json из базы на клиент и обратно. Это просто факт. Зачем вы пытаетесь это отрицать?

                                                                                                                            0
                                                                                                                            property based testing, алгебраические эффекты, FP, всякие тонкости реализаций DI и пр.

                                                                                                                            Но ведь все эти вещи обсуджают и клиентщики, плюс… куча всего дополнительного.

                                                                                                                              0

                                                                                                                              Да :) Всё так. Но я бы не стал так умалять заслуги серьёзного backend-а. Помимо своего головняка, у них там много всяких хитрых side-задач из нерелевантных областей. Могут припахать и какой-нибудь ML писать. Была бы голова на плечах, а чем её загрузить — найдётся. Не важно какая область. У нас backend на scala2, а это коммьюнити очень одарённых "извращенцев". Они себе геморрой на голову всегда придумают :D

                                                                                                                              0

                                                                                                                              Толковые программисты, как раз-таки стараются сделать всё как можно проще, а не тащить в проект все самые хайповые концепции, чтобы вводить в проект нового разраба нужно было 2 месяца.

                                                                                                                                0
                                                                                                                                Это относительно, иногда конторе все-таки выгодно наговнокодить и продать больше людей ;)
                                                                                                                                  0

                                                                                                                                  Легко сказать, да трудно сделать. Я конечно понимаю, что у вас святая вера в то, что ваши решения простые, правильно выстроенные, и вообще $mol впереди планеты всей.


                                                                                                                                  Но, исходя из сотен ваших сообщений, складывается ощущение, что это всё так только в вашей голове. И при любой критике выясняется что все ошибаются, не правильно мыслят, не под тем углом смотрят, не теми линейками меряют.

                                                                                                                                    0

                                                                                                                                    И применяют демогагические приёмы в дискуссии, да. Типичная ситуация, когда нечего привести в пример архитектурной сложности и кривизны. Ибо чтобы вести аргументированную дискуссию, надо разобраться в предмете обсуждения. Куда же проще вместо этого обвинить оппонента в слепой вере. Это не делает ваши слова сколь-нибудь весомыми.