Подтвердить что ты не робот

Повторное имя модуля для каждого компонента модуля

В знаменитых рекомендациях по лучшей практике для блога Angular Структура приложения сообщается новая рекомендуемая структура проекта angularjs, которая теперь является компонентно-ориентированной, а не функционально-ориентированной, или как указано в исходной проблеме github - "Организовано по функциям".

В блоге сообщается, что каждый файл внутри каждого модуля должен начинаться с имени модуля, например:

userlogin/
    userlogin.js
    userlogin.css                
    userlogin.html                
    userlogin-directive.js
    userlogin-directive_test.js
    userlogin-service.js
    userlogin-service_test.js

Возникает вопрос: какова точка, плюсы и минусы повторения имени модуля внутри каждого имени файла в модуле, в отличие от того, что файлы называются функционально? Например:

userlogin/
    userlogin.js
    userlogin.css                
    userlogin.html   
    controllers.js             
    directives.js
    services.js

Я спрашиваю, что я исхожу из мира Django, где есть несколько схожая идея: проекты и приложения. Каждое приложение обычно имеет собственные models.py, views.py, urls.py, tests.py. В именах script нет повторяющегося имени приложения.

Надеюсь, что я не пересекаю линию, основанную на мнениях, и есть законная причина для подхода.

4b9b3361

ОТВЕТЫ

Ответ 1

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

"Обзорность" - это возможность организации кода (структура папок, именования файлов, метаобъекты и т.д.), чтобы обеспечить быстрый и информативный обзор реализованного программного обеспечения.

Значение "обзорности" экспоненциально возрастает с размером базы кода и командой разработчиков, работающей над проектом * по следующим причинам (неисчерпывающий список):

  • Когда кодовая база велика, вероятность того, что некоторые части кода останутся нетронутыми в течение определенного периода времени, увеличивается (как увеличивает продолжительность этого "холодного" периода).

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

"Итак, хорошо," обзорность "важна. Поэтому у нас есть эта хорошая, компонентно-ориентированная структура и т.д. Но почему префикс каждого файла с именем компонента?"

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

...               
userlogin.html                
userlogin-controller.js
...

Если это не для префикса, вы получите различные заказы в зависимости от имени компонента. Например:.

...                       ...                      ...
controller.js             controller.js            bookself.html
...                       ...                      ...
service.js         VS     service.js        VS     controller.js
...                       ...                      ...
userlogin.html            zombi.html               service.js
...                       ...                      ...

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

...                             ...                         ...
userlogin.html                  zombi.html                  bookself.html
...                             ...                         ...
userlogin-controller.js    VS   zombi-controller.js    VS   bookself-controller.js
...                             ...                         ...
userlogin-service.js            zombi-service.js            bookself-service.js
...                             ...                         ...

Это может показаться тривиальным, но это не так; тем более, что к нему привыкают. Обратите внимание, что человеческий ум очень хорош в распознавании визуальных шаблонов (например, созданных представлением структуры папки и файла tree- node в файловом проводнике).

т.е. контроллеры не находятся в файле с именем "<component> -controllers.js".
Он находится в первом файле, имя которого значительно длиннее предыдущих файлов.
Служба (если есть) находится в файле с меньшим именем в конце и т.д.

Измените это (т.е. повредите порядок из-за стартовой буквы или повредите их относительную длину из-за длинного/короткого имени компонента), и у вас есть ситуация, похожая на необходимость читать что-то с жесткого диска, вместо этого просто прочитав его из ОЗУ. (Разработчик не хочет туда идти))

<суб > *: На самом деле, это то, что мы называем "поток команды разработчиков", что важно здесь, то есть, как часто покидает член команды (например, работать над чем-то другим, покидая компанию и т.д.) Или вводится новый член.
 Обычно, чем больше команда, тем больше поток. Суб >

Ответ 2

Все о организации больших проектов (база кода):

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

Из мира ASP.NET, где проекты огромны, мы имеем:

Решения → управление Проекты (сборки) → с папками → и подпапками для файлов.

Таким образом, проект ASP.NET MVC будет иметь Домашний контроллер в папке Controllers проекта MVC Presentation и Views в папке Виды.

При использовании AngularJS в моих проектах мне нравится подход к присвоению имен

App(Module)-type(directive/service)-(sometimes more detail)

Это дополнение к именам папок для приложений и наличие директив и служб в папках для их типов с папкой с именем после приложения. > и приложение, часто называемое функционально или после ASP.NET View (например, мой просмотр может быть Account-Login).

Все это, потому что мои проекты очень большие. В итоге у меня появилось много AngularJS apps, безумное число directives и даже четное число services.

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

Ответ 3

TL;DR; В то время как другие ответы не являются ошибочными в большинстве своих точек, они не могут распознать важность инструментов навигации по файлам, доступных сегодня разработчикам.

Быстрое перемещение файлов проекта

Как только мы будем хорошо знакомы с проектом, мы захотим перемещаться между файлами, не глядя на исходное дерево. Наша схема именования будет играть важную роль в том, чтобы мы могли быстро перемещаться. Мы можем быстро перейти к файлу, введя фрагменты имени файла. Например, если ваше имя модуля forsee, вы можете увидеть список файлов forsee javascript, введя fo.js в поле поиска файлов (при условии, что ваш редактор имеет эту функцию). На вкладке "Источник инструмента Chrome Dev Tools" встроена эта функция. Вы можете увидеть его в действии, здесь (откройте инструменты dev и нажмите Cmd + O):

Fragment Search Screenshot 1

Раньше я думал, что для поиска необходимо было добавить все имена файлов с именем модуля, но потом понял, что это совсем не так. Мы можем так же эффективно искать fo/js:

Fragment Search Screenshot 2

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

Overviewability

Я согласен с ExpertSystem в том, что группировка файлов позволяет вам лучше видеть вещи с первого взгляда. Тем не менее, еще раз добавление имени модуля действительно не требуется. Скорее, активируйте соответствующую опцию в редакторе:

Sort by Type Screenshot

На скриншоте выше я активировал параметр "Сортировка по типу", чтобы включить сортировку файлов по расширениям файлов.

Почему мы не должны

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

Предостережения

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

Заключение

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

BTW: Я называю файлы js в соответствии с предложением ExpertSystems. То есть, dialog.js, dialog-ctrl.js, dialog-services.js и т.д. Это имеет смысл по причинам, которые он изложил, но когда модуль имеет несколько партиций, лучше не следовать этому шаблону именования html файлы.суб >

Ответ 4

Я написал об этом в одном из сообщений

Модули часто имеют перекрывающиеся функции

Предположим, вы создали страницу настроек учетной записи. Учетная запись администратора может sendNotifications, где учетная запись пользователя может updateNotifications. Учетные записи администратора и пользователя могут updateAvatar.

Описывает функции, а также отношения

Компоненты, абстрагированные в отдельные модули, файлы и папки, легче работать.

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

angular.module("account",  [
  "account.updateAvatar",
  "account.sendNotifications", 
  "account.updateNotifications"
]);

Но определение родительских модулей для этих функций способствует организации и наследованию:

angular.module("account",  [
  "account.common",
  "account.admin", 
  "account.user"
]);

angular.module("account.common",  [
"account.common.updateAvatar"
]);

angular.module("account.admin",  [
"account.admin.sendNotifications"
]);

angular.module("account.user",  [
"account.user.updateNotifications"
]);

Функциональные модули могут следовать аналогичной схеме:

angular.module("account.common.updateAvatar",  [ 
"account.common.updateAvatar.services",  
"account.common.updateAvatar.controllers",  
"account.common.updateAvatar.directives",
"account.common.updateAvatar.filters"
]);

Виды и активы:

account.common.updateAvatar.less
account.common.updateAvatar.tpl.html
account.common.updateAvatar.heading.tpl.html
account.common.updateAvatar.body.tpl.html

Точечная нотация может включать легкие шаблоны глобуса

Скомпилируйте все ваши частичные части HTML в кешированный JavaScript:

module.exports = function(grunt) {
  grunt.initConfig({
    html2js: {   
      partials: {
        src: ["src/**/*.tpl.html"],
        dest: "build/js/app.tpls.js",
        module: "app.tpls"
      }
    }
  )};
};

Совместить все ваши JavaScript-адроны независимо от вашего пользователя JavaScript:

module.exports = function(grunt) {
  grunt.initConfig({
    concat: {
      admin: {
        src: ["src/**/*.admin.*.js"],
        dest: "build/js/admin.js"
      },
      user: {
        src: ["src/**/*.user.*.js"],
        dest: "build/js/user.js"
      }
  )};
};

Ответ 5

Как заявила ExpertSystem, ваша текущая структура каталогов не относится к блогу Рекомендации по лучшей практике для Angular Структура приложения.

Я совместно с ExpertSystems, а также Гил Бирман, что подход для проектирования структуры приложения должен быть модульным. Как вы знаете, сам Angular следует за модульной структурой, так что у вас есть несколько модулей или один модуль Angular, который вам нужно подумать в соответствии с функциональностью, на которую вы обслуживаете. Например, если у вас есть функция "CountDown", она должна иметь свою собственную структуру.

Почему это важно?

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

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

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

4. Реализация TDD:. Эта структура может использоваться для запуска тестовой разработки (TDD). Преимущества TDD упоминаются здесь в этой статье

Разница между разработкой и производственным кодексом/структурой

В разработке вы можете иметь структуру в соответствии с функциональностью. Однако, чтобы улучшить производительность вашего веб-приложения (или гибридного мобильного приложения), лучший способ сделать это - объединить все файлы, минимизировать его и обфускать с помощью GRUNT. Будет давать образец файла GRUNT для него. Вы можете запускать script каждый раз во время развертывания, используя любой инструмент непрерывной интеграции, например, Jenkins.