Има много добра причина и тя е за подобряване на много важен аспект за всяка нетривиална кодова база (особено когато са включени големи екипи от разработчици), а именно това, което наричаме „обзорна видимост“.
„Възможност за преглед“ е способността на организацията на кодовата база (структура на папки, именуване на файлове, мета-обекти и т.н.) да предоставя бърз и информативен преглед на внедрения софтуер.
Значението на „обзорността“ се увеличава експоненциално с размера на кодовата база и този на екипа разработчици, работещ по проекта* поради следните причини (неизчерпателен списък):
Когато кодовата база е голяма, вероятността някои части от кода да останат недокоснати за определен период от време се увеличава (тъй като се увеличава продължителността на този "студен" период).
Когато нови членове се присъединят към екипа, вие искате те да бъдат запознати възможно най-бързо (и да не ги разочаровате в процеса). „Обзорна възможност“ помага да се осигури добра абстракция на високо ниво на целия проект и обикновено дава добра представа за това как работят нещата (по-често създава усещане за познатост; все едно сте виждали кодовата база преди – въпреки че ти не си).
"Така че, добре, "обзорността" е важна. Ето защо имаме тази хубава структура, ориентирана към компонентите и т.н. Но защо да поставяме пред всеки файл името на компонента?"
Е, може да звучи смешно, но добавянето на префикс към всички имена на файлове, свързани с компоненти, гарантира конкретен ред. напр. частичният 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".
Той се намира в първия файл, чието име е значително по-дълго от предишните файлове.
Услугата (ако има такава) се намира във файла с по-малко име в края и т.н.
Объркайте това (т.е. объркайте реда поради началната буква или объркайте относителната им дължина поради дълги/къси имена на компоненти) и ще имате ситуация, подобна на това, че трябва да прочетете нещо от твърдия диск, вместо просто да четете от RAM паметта. (Никой програмист не иска да отиде там :))
*: Всъщност тук е важно това, което наричаме „поток на екипа на разработчиците“, т.е. колко често член на екипа ще напуска (напр. за да работи върху нещо друго, напускане на компанията и т.н.) или ще бъде представен нов член .
Обикновено колкото по-голям е екипът, толкова по-голям е потокът.
person
gkalpak
schedule
05.08.2014
