На это есть очень веская причина, и она заключается в улучшении очень важного аспекта любой нетривиальной кодовой базы (особенно когда задействованы большие группы разработчиков), а именно того, что мы называем «обзорностью».
«Обзорность» — это способность организации кодовой базы (структура папок, имена файлов, метаобъекты и т. д.) обеспечивать быстрый и информативный обзор реализованного программного обеспечения.
Значимость «обзорности» экспоненциально возрастает с увеличением размера кодовой базы и размера команды разработчиков, работающих над проектом*, по следующим причинам (неполный список):
Когда кодовая база велика, вероятность того, что определенные части кода останутся нетронутыми в течение определенного периода времени, увеличивается (по мере увеличения продолжительности этого «холодного» периода).
Когда новые участники присоединяются к команде, вы хотите, чтобы они как можно скорее были в курсе (и не разочаровывались в процессе). «Обзорность» помогает обеспечить хорошую высокоуровневую абстракцию всего проекта и обычно также дает хорошее представление о том, как все работает (чаще всего это создает ощущение знакомости; как будто вы видели кодовую базу раньше, хотя у вас нет).
"Итак, хорошо, "обзорность" важна. Вот почему у нас есть такая приятная, ориентированная на компоненты структура и т. д. Но зачем ставить перед каждым файлом имя компонента?"
Что ж, это может показаться забавным, но префикс всех имен файлов, связанных с компонентами, обеспечивает определенный порядок. Например. частичный 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
... ... ...
Это может показаться тривиальным, но это не так; особенно когда к этому привыкаешь.
Обратите внимание, что человеческий разум очень хорошо распознает визуальные шаблоны (например, созданные древовидным представлением структуры папок и файлов в файловом проводнике).
т.е. контроллеры не находятся в файле с именем "‹component›-controllers.js".
Они находятся в первом файле, имя которого значительно длиннее, чем у предыдущих файлов.
Служба (если есть) находится в файле с меньшим именем в конце и т. д.
Испортите это (т.е. испортите порядок из-за начальной буквы или перепутаете их относительную длину из-за длинных/коротких имен компонентов), и вы сами окажетесь в ситуации, похожей на необходимость чтения чего-то с жесткого диска, вместо того, чтобы просто читать это из ОЗУ. (Ни один разработчик не хочет туда идти :))
*: На самом деле здесь важно то, что мы называем «потоком команды разработчиков», то есть как часто член команды будет уходить (например, чтобы работать над чем-то другим, покидать компанию и т. д.) или будет представлен новый член. .
Обычно, чем больше команда, тем сильнее поток.
person
gkalpak
schedule
05.08.2014
