Моя короткая карьера была затоплена React.
Перед выпуском я начал изучать фреймворк с Vue 2.x и присоединился к компании в состоянии, в котором я думал, что в то время все было в порядке, и теперь я полностью оглядываюсь назад. Затем я включил состояние смертельной опасности с помощью React, от компонентов класса к функциональным компонентам, от Redux к Recoil, от Antd к MUI...
Не так давно был успешно завершен проект, на котором я пробыл более 2-х лет, и я собирался на новый проект.Новый проект будет использовать Angular, поэтому я начал прощаться с React, которым пользуюсь с момента выпуска, и начал изучать этот фреймворк, о котором редко все упоминают.
придется
Оглядываясь назад на последние несколько лет, чтобы сказать, что React принес мне больше всего, я думаю, что это могут быть идеи, парадигма программирования. Чтобы понять новые функциональные компоненты React, я пошел изучать FP, но я не фундаменталист, поэтому я, конечно, не согласен с тем, что для изучения FP нужно изучать Lisp.
За это время я нашелмаленькая желтая книгаавторKyle SimpsonТакже написал специальное введение в FP для JSer.Книга, в предисловии к книге я глубоко убежден:
The way I see it, functional programming is at its heart about using patterns in your code that are well-known, understandable, and proven to keep away the mistakes that make code harder to understand.
Да, роль парадигмы программирования состоит в том, чтобы позволить людям лучше организовывать и понимать код Парадигма программирования должна служить человеку, который пишет код, а не тому, кто подробно следует каждому правилу парадигмы программирования и понимает каждое неясное и непонятное. сложный понять концепцию.
I believe that programming is fundamentally about humans, not about code. I believe that code is first and foremost a means of human communication, and only as a side effect (hear my self-referential chuckle) does it instruct the computer.
Agile должен быть ориентирован на людей, как и написание кода. Что нам нужно сделать, так это понять саму парадигму программирования и роль, стоящую за ней, может быть, когда-нибудь в будущем вы вдруг поймете, что эта штука, которую я так долго использую, имеет такое интересное название, или, может быть, вы никогда не узнаете. непонятно, что это за понятие:
A monad is just a monoid in the category of endofunctors.
Монада есть не что иное, как моноид в категории автофункторов..
Означает ли это, что я не могу играть в FP, если не понимаю? Тогда я должен стоять в конце цепи презрения, и игроки на Haskell и Lisp указывают мне в нос и насмехаются: Посмотрите на этого парня, он ничего не знает, его также называют FP?
У меня нет ответа на этот вопрос, может быть, я могу оставить его вам для обсуждения. Но здесь я хотя бы понимаю, почему хуки React называются «хуками», почему существует хук под названием «useEffect», я также понимаю, почему все говорят не использовать хуки для реализации жизненного цикла компонентов класса.
В дополнение к написанию самого React я также пробовал чистые функции, частичные функции, каррирование, композицию и бесточечный стиль кода, и я получил некоторые преимущества и принес некоторые неудобства.
Возможно, эти идеи — самый большой побочный эффект изучения React для меня (смеется.
терять
В отличие от того, что React полностью основан на FP, мое краткое знакомство с Angular показало, что он охватывает ООП по всем направлениям. Точно так же, как когда React переключился с компонентов класса на функциональные компоненты в то время, вам сначала нужно было полностью изменить мышление парадигмы программирования, чтобы хорошо понять Angular. Это, в свою очередь, заставило меня пересмотреть многие идеи ООП, от которых я давно отказался.
В этот момент я не могу не думать о тренировочном лагере TDD в компании. После того, как домашнее задание было выполнено, я пошел к тренеру, чтобы объяснить. Во время объяснения тренер говорил о возможностях абстракции, слоях изоляции и анти- - коррозионные слои. В то время я понял, что мои способности к объектно-ориентированной абстракции были действительно плохими по сравнению с моими друзьями из бэкенда, которые у меня были только во время учебы в колледже. После размышлений кажется, что его «использует» React, и я почти потерял эту часть способности.
Честно говоря, я давно не сталкивался с компонентами класса React, первому проекту было всего несколько месяцев. Хотя последние два проекта пошли на написание Java, первый был некоторой подделкой, больше похожей на выполнение DevOps, а более поздние проекты пошли на написание Java BFF, Абстракции нет вообще, это все отображение данных. Затем я вошел в проект, реализующий «стремление к техническому совершенству», и стал первой группой людей, которые съели функциональные компоненты.
Таким образом, мое знакомство с компонентами класса было всего несколько месяцев, когда я был выпускником.
Затем, когда я увидел внедрение зависимостей в документации Angular, я мог лишь изредка всплывать несколько концепций: SOLID, развязка. Не вдавайтесь в подробности, я даже не знаю, верны ли те вещи, которые я выдвигаю. Поэтому я могу полагаться только на собственную память при поиске по почте связанных статей о конкурсах в блогах.
Кажется, я потерял ООП.
Лучшее время для посадки дерева было десять лет назад, а затем и сейчас.
постигать
Выскочив из React all в FP, я обнаружил, что мир не черно-белый. Говорят, что он полностью охватывает ООП, но на самом деле вы можете легко найти тень FP в Angular — использовать конвейер для обработки данных и использовать Rx для обработки запросов.
Поскольку парадигма программирования ориентирована на людей, она по своей сутине должно быть против, они, очевидно, могут дополнять друг друга и заниматься тем, в чем они хороши в своих областях, даже если это один и тот же проект. Я привык видеть сцену, где ссорятся два лагеря, и кажется, что именно такая сцена мне и нужна.
Итак, я вспомнил проблему субподряда проекта, которую я однажды обсуждал с вами на проекте, и окончательный вывод заключался в том, что стратегия субподряда ООП, основанная на объектах и доменах, в большинстве случаев лучше, чем чистый метод FP. Это может сделать функцию более централизованной и облегчить каждому поиск того, что он ищет.
Но оглядываясь назад и думая спокойно, хотя я буду хорошо изучать ООП, я, вероятно, не буду в настоящее время подробно изучать связанные методы моделирования. Потому что в моей текущей рабочей среде я не видел сцены, где фронтенд-студентам нужно глубокое понимание методов моделирования.
Судя по собственному опыту, я видел и участвовал в обучении DDD, а также практиковался с нуля до единицы при создании проектов с бэкенд-партнерами проекта. Но в случае небольшой практики весь процесс не может избежать проклятия обучения и забывания учиться. Наверное, единственная польза в том, что когда меня поймают за работой на бэкенде, я смогу понять, почему они так организуют код, а что касается процесса моделирования, то я, скорее всего, не буду участвовать в процессе того, чтобы меня поймали за работой. (Конечно, если у вас есть соответствующий опыт, пожалуйста, разбудите меня. Например, как фронтенд-друг, вам нужно освоить метод моделирования, иначе вы не сможете выполнить работу)
Не ограничивайтесь стеком технологий На самом деле, я всегда немного понимал это предложение раньше, хотя сейчас мое понимание может быть не очень сильным. Но когда вы выпрыгиваете из рамки и думаете о структуре мыслей человека, у вас могут появиться и другие мысли. Изучение нового фреймворка, нового языка может не быть проблемой для Thoughtworker, поэтому мы можем пойти дальше и подумать о вещах, которые кажутся «иллюзорными».
Не будьте обрамлены вашей рамкой.
Небольшая станция, можно глянуть :)teobler.com