Первоначально это было опубликовано в tiagojdf.
Когда я только начинал как младший программист, я всегда терялся, глядя на внутренний код.
Я предположил, что отчасти это было из-за того, что я был младшим разработчиком; что я использовал javascript вместо того языка, который использовался в этом бэкэнде; и что фронтенд-разработка сильно отличалась от бэкенда.
Я работал с бэкендами на php и python, с несколькими фреймворками, и каждый раз первые пару недель я терялся. Независимо от того, сколько раз я сталкивался с паттерном MVC (Model-View-Controller), я всегда чувствовал себя потерянным, и мне было трудно понять, в каких файлах находится код, который мне нужно изменить.
По мере того как я работал все больше и больше над такими проектами и приобретал опыт в архитектуре программного обеспечения, я понял, что проблема была не столько в сложности кода или шаблонов, сколько в том, как код был организован и структурирован в разные папки и файлы.
Если вы занимались внешним интерфейсом до появления React и Component frameworks, вы, вероятно, столкнулись с той же проблемой. Файлы HTML находились в папке шаблонов, css в стилях и js в скрипте. Затем эти папки будут иметь несколько уровней подпапок, разделенных по шаблону, другие по функциональности, а третьи будут просто случайными, например, утилиты, активы или любое другое имя, которое кажется удобным в то время. Вещи были разделены по формату, шаблону или какой-то другой случайной логике, которая имела какой-то смысл. Старшие инженеры в проекте всегда чувствовали, что архитектура имеет смысл из-за привычки, и не легко сочувствовали трудностям новых разработчиков.
А теперь… Вы когда-нибудь слышали о правиле Хебба? Правило Хебба исходит из неврологии и может быть упрощено следующим образом:
Нейроны, которые активируются вместе, связаны друг с другом
Одним из основных выводов этого правила является пластичность мозга. Пластичность мозга заключается в том, что когда разные нейроны работают вместе для достижения чего-либо, все они создают более прочные связи и группируются в сети.
Код должен быть похожим. Код, который работает вместе для достижения чего-либо, становится тесно связанным и должен быть сгруппирован.
Если у вас есть шаблон, css, js и некоторые ресурсы, отображающие определенный маршрут, все они должны находиться в одной папке, представляющей этот маршрут. Если они образуют повторно используемый компонент, все они должны находиться в папке этого компонента. Это касается и бэкенда. Если у вас есть API с определенным представлением, которое использует форму и определенный сериализатор, вместо представления в папке со всеми представлениями форма в одном со всеми формами и сериализатор в одном со всеми сериализаторы, эти файлы должны быть вместе.
Как только вы это поймете, вы поймете, почему JSX, который в то время противоречил всем соглашениям, теперь так широко распространен и проложил путь для компонентных фреймворков. До появления JSX было обычным делом разделять код по формату файла, а не по функциональности. Добавление функции означало добавление 3 новых файлов и изменение еще нескольких в разных папках и подпапках. JSX позволяет логике, шаблону и стилю сосуществовать в одном месте; упрощая создание или изменение кода при работе над определенной функциональностью.
Это относится и к крючкам. До использования хуков ваша логика в вашем компоненте будет распределена по разным методам жизненного цикла. Теперь вы можете собрать логику, которая работает вместе, в виде пользовательского хука.
Прежде чем я начну, позвольте мне сказать, что это не означает, что у вас должен быть монолит со всем вашим кодом. Нет, это означает, что вы должны группировать и разделять свой код на основе функциональности.
Подвести итог:
Код, который работает вместе, остается вместе
Вы можете послушать это на Spotify, Apple Podcast или Google podcasts.
Первоначально опубликовано на https://dev.to 16 марта 2021 г.
