Here is my two cents
Gondolkoztam nehany mondatodon, de vegulis nincs ertelme kiragadni oket, ezert inkabb megprobalok a problemadra vezeto okot feltarni.
Minden front end fejleszto mast ert alatt javascript fejlesztesen, fuggoen attol h milyen az adott project.
Reszletezve frameworkok szerint (sajat/standard alacsony szintu/standard magas szintu), elotapasztalat szerint (semmi/backend) es a feladat szerint (vekony kliens/vastag kliens).
Ha ezektol fuggetlenul probalnank egy egzakt feltetelrendszert felallitani h mi a front end fejleszto szukseges es elegseges feltetelei akkor mindezt figyelembe kellene vennunk es kb megkapjuk azt a szintet amit egy nemzetkozi outsourcing cegnel elvarnak.
A nyelvet legeloszor is ismerni kell, Closure-ket nem agyba fobe hasznalunk mivel fogjak a kontextust, hanem a leheto legkisebb kontextust osztjuk meg es mindig takaritunk magunk utan (nem csak a dom-ban). - enelkul a kodunk fele proxy utasitasokkal lesz tele (vagy that/self = this; fele antipattern-el) es tobbek kozott olvashatatlan is lesz.
A nyelv ismerete utan alapveto a module pattern betartasa megpedig nem esz nelkul hanem a clear separation of concerns menten.
Ha ezek nincsenek meg a fejleszto csapatban mindenkinel es nincs egy egyseges developer guideline akkor nagy baj van.
De ha megis ez meg mindig nem elegseges, kellenek a static code analyserek mint a jshint/csshint valamint ezek mellett a unit es integracios tesztek (a 100 code coverage helyett ugye erdemesebb az edge casekre fokuszalni).
Viszont ha van egy egyseges developer guide-unk ami megszabja hogyan irjuk a moduljainkat, amik teszteltek onmagukban es egyuttmukodve is, akkor egeszen mas szintu problemak merulnek fel, mint hogy tobb esemenykezelo egymas workflowjaba bekavar, ami ugye a side-effecteknek koszonheto, plane ha aszinkron dolgokat vegzunk de nincs jol atgondolva.
(Persze ekkor is lehet latszatra szep kodot irni ugy h a vegeredmeny egy fabatkat se erjen...)
Ennek a developer guidelinenak a formai kovetelmenyeken tul le kell irnia h diszkret modulokat kell irni, ne pisaljunk bele a kozos medencebe, ezert hasznalunk pl. namespacelt esemenyeket h amikor leiratkozunk egy dom noderol csak a mi listenerunket vegyuk le, maset ne.
Ezen tul a frameworkokkel az a gond, h onnantol az adott fejleszto nem csak hasznalja a frameworkot, hanem a problema megoldasara fog tudni egy framework specifikus megoldast amit a framework nelkul csak sok izzadas aran tudna elerni.
Ezt kikerulendo rendkivul fontos h a csapatban minden fejleszto ismerje a framework belso mukodeset, minden apro magicet, amit csinal es ugye sajnos ez sokszor nem elmondhato es a jovobeni problemak elore lathatok.
Amire vegulis ki akartam lyukadni h egy nyelv mindegy milyen, csak annyira jo mint amennyire a csapat ismeri.
Erre egy jo pelda ledokumentalasa azert nem eletszeru, mert itt olyan kodrol van szo ami jol skalazodik nagyban, tobben fejlesztik es karbantartjak, ezert valoszinuleg zart forras, mint pl. azok is amikrol en tudok. - itt nem is igazan maga a kod kritikus mert ugye vegeredmenyben ott lesz a kliensen a cache-ben, hanem a meg nem releaselt uj funkciok, amik a conversiont emelik a versenytarsakkal szemben.
A nyilt forras ugye mas teszta, de hatha valaki mas tud peldat emliteni.
De roviden valaszolva a kerdesedre menj el egy multinacionalis software outsourcing ceghez (onsite lehetoleg), es ott remelhetoleg lesz lehetoseged a pozitiv pelda megismeresere is (leszamitva h rovid projecteken ott is mehet a ganyolas sajnos).
---
return NEVER;