Share
Organisationen kan göra eller bryta underhållet av en ansökan. Med mindre applikationer är organisationen uppenbarligen tydlig; Men eftersom applikationen växer och som antalet applikationsutvecklare och avancerade ingenjörer som producerar kod ökar kan den mer förvirrande organisationen bli. I det här inlägget kommer vi att gå över några grundläggande begrepp för att hålla ansökningar organiserade så att finna relevant kod är en effektiv och systematisk process.
JavaScript bör scoped på ett effektivt sätt.
Låt oss ta en stund och överväga hur Rails och Wordpress-team organiserar sina projekt. Chansen är att du har antagligen arbetat med den ena eller den andra. Båda ramarna har en uppsättning standardstruktur.
När du skapar en Rails-applikation hanterar Rails mycket av de primära organisatoriska behoven för dig. Eftersom den är baserad på MVC, innehåller standarduppställningen Rails en mapp med etiketten "app", som innehåller mapp / visning / kontrollermappar. Det ger också "helpers" och "mailers", de styrenhetsförlängningar som hjälper till att fylla i mellanrummen mellan styrenheter och modeller.
Rails genererar också några andra objekt på samma nivå som "app" -mappen, till exempel konfiguration, loggning, databaser, tillfällig / caching, test och några andra bitar. Det som är särskilt intressant för denna diskussion är app och offentliga mappar. Den offentliga mappen är där statiska tillgångar serveras från, inklusive alla icke-dynamiska HTML-, CSS- och JavaScript-filer.
När du arbetar med Wordpress är namnet och strukturen betydligt mindre uppenbart.
... programmet är byggt för användare ...
Konventioner exponeras genom dokumentationen. I synnerhet arbetar utvecklare sannolikt inom ett tema, som ligger i wp-innehållet / teman / katalogen. Detta tema har en rad filer med specialnamn, främst baserat på vyer. en functions.php fil fungerar som en "controller" av sorter, där en utvecklare kan lägga funktioner för att skilja dem från synpunkterna. Men Wordpress teman ofta leriga vattnet mellan logik och presentation. Exempelvis är databasfrågor implicita av filnamn, men manipuleras ofta genom att ändra frågan innan looping genom de returnerade resultaten. Denna manipulation abstrakt inte på samma sätt som en controller skulle (och naturligtvis, Wordpress är inte någonstans nära MVC, så vi kan inte förvänta oss denna typ av organisation).
Båda dessa ramar är extremt populära, och båda använder sin egen implicita strukturering. De kräver absolut att utvecklare förstår hur systemet fungerar för att vara effektivt. I våra egna applikationer bör vi ta hänsyn till detta organisationsparadigm och skapa ett systematiskt tillvägagångssätt för att strukturera applikationer. Detta spelar ut mycket olika för varje enskild applikation.
De ovan nämnda ramarna kräver inte att utvecklare definierar strukturen. de är "förkopplade" för att arbeta på ett visst sätt.
En viktig orsak till att robusta ramar ofta abstraherar dessa konfigurationer och tillhandahåller standardstrukturer är så att människor kommer att börja utveckla en communitystandard baserad på standardstrukturen.
Undvik att ignorera standarder vid organisationen av din ansökan!
Om du är bekant med Rails, kan du troligen titta på ett Github-arkiv och veta om det är en Rails-app bara genom mappstrukturen - Rails har en dokumenterad standard.
Undvik att ignorera standarder när du organiserar din ansökan! Det är högst sannolikt att om du organiserar en applikation på företagsnivå, handlar du om modulära, diskreta servicebaserade mini-applikationer. Det kan till exempel vara så att du har flera applikationer som är byggda med en eller flera olika ramar, eller de kan rullas för hand och arbeta i samverkan med varandra, och utsätta API-skivor som ger krokar för de andra tjänsterna. Var och en av dessa diskreta tillämpningar följer sannolikt de normer för ramverket som den byggdes på. Dessa standarder finns för att de är sättet som denna ram utformades för att fungera. Om du försöker ändra dessa standarder inom en diskret applikation hamnar du sannolikt slösa mer tid konfigurera än att egentligen bygga en arbetsansökan.
I praktiken betyder det att de saker som utsätts från en tjänst till en annan borde fungera på ett enhetligt sätt, och de delar som är interna till en tjänst bör fungera som det är bäst för den aktuella tjänsten, förmodligen driven av vilken ram eller som helst teknik stack som tjänsten körs på.
Kom ihåg att i slutet av dagen är applikationen byggd för användare, och användarna känner inte till eller uppskattar separation av de separata tjänsterna.
De förstår istället applikationen och erfarenheten som en bit, och den ena delen kommer främst att gynnas av enhetlighet på toppnivå.
Så vad behöver vara enhetlig?
När ansökan växer ... kan den mer förvirrande organisationen bli.
Rutter (URL-strukturer) är en av de viktigaste definierande faktorerna för hur en webbapplikation fungerar. Det är viktigt att dina vägar följer en enhetlig struktur. Till exempel, när du visar ett "användarkonto" med en URL som / Användare / 5 var 5 är användarens primära nyckeltals-ID, bör du inte använda plural för ett annat singularobjekt, t.ex. / Widgets / 16. I stället borde det vara / Widget / 16. Detta hjälper inte bara utvecklare att vara konsekventa, men ger också klarhet och enhetlighet för användarna. Det spelar ingen roll vad du väljer för din färdstruktur, så länge det är konsekvent på den användarorienterade nivån.
Detta är extremt viktigt för intern utveckling, och det är ännu viktigare för mjukvaruprodukt / serviceutveckling där ett API är utsatt för allmänheten. Om dina API-samtal har underskrifter som ordseparatorer, använd inte en kamel eller separerad nyckel i ditt API någon annanstans. Om du använder ordet "count" för att bety "returnera detta antal objekt", använd inte något som "count_per_page" för att betyda samma sak på annat håll i samma (eller ett relaterat) API. Detta är slarvigt API-design. Utveckla en standardsyntax och håll fast vid den; notera att det här ofta hanteras av välutförd ruttdesign i REST API.
På en generell nivå, när du arbetar med "foo widgets" (godtyckliga objekt eller åtgärder) i din ansökan, se till att du använder samma terminologi i alla dina program. Till exempel, medan det kan vara vanligt att använda Rails för att använda den "offentliga" katalogen, har du kontroll över vad som går in i det.
Använd inte en "js" -mapp för en ram och en "skript" -mapp för en annan ram.
Ringa inte datormodeller "orange_items" i en ram och "OrangeItems" i en annan, såvida inte språket eller ramen uttryckligen kräver det av en funktionell anledning. Se även till att det finns ett konsekvent system och "grammatik", och se till att skillnaderna mellan de separata tjänsterna är väl dokumenterad och motiverad. Dessa typer av signaler och enhetlighet kommer i hög grad att bidra till förståelsen av klassificeringar av objekt över en applikation.
Spegelvägar till mappar och filer hjälper till att hålla en applikation organiserad. Du kan till exempel ha mappar för CSS, JavaScript och bilder i dina "offentliga" eller "statiska" mappar. Skapa en struktur av mappar som kartlägger dina rutter, visningar, kontroller eller andra liknande strukturer kan hjälpa till att hålla din CSS modulerad. Du kan sedan använda ett verktyg som CodeKit för att sammanfoga dessa filer till en enda minifierad fil. Naturligtvis kan du också ha en global.css för regler som gäller hela hela applikationen. Se nedan för ett exempel (.rb är för Ruby, men det kan gå för någon MVCs ramorganisation).
- root / - app / --- modeller / ---- foo.rb ---- bar.rb ---- baz / ----- widget.rb --- views / ---- global. html.erb ---- foo.html.erb ---- bar.html.erb ---- baz / ----- widget.html.erb --- controllers ---- foo.rb - - bar.rb - public - CSS --- global.css --- foo.css --- bar.css --- baz / ---- widget.css - JS --- global.js - - foo.js --- bar.js --- baz / ---- widget.js - Bilder / --- global / ---- image.jpeg --- foo ---- image.jpeg --- bar ---- image.jpeg --- baz / ---- widget / ----- image.jpeg
Man kan snabbt se att det inte skulle vara svårt att hitta specifika CSS, JavaScript, modeller etc för en viss del av ansökan.
Rutter (URL-strukturer) är en av de viktigaste definierande faktorerna för hur en webbapplikation fungerar.
Det bästa sättet att tänka på detta är att separera dina filer till "områden" på din webbplats. Till exempel kanske du har en applikation som innehåller ett "admin" -område och ett "profil" -område. Du kan skapa en global.css fil för att hålla objekten / reglerna som gäller för båda områdena (inklusive en återställning, vissa typografiregler, färger etc.) och skapa sedan specifika filer som gäller för de separata områdena för innehållsregleringsregler som inte delas. På det här sättet, som en utvecklare arbetar på en viss sida, kommer de att stanna i en eller två filer och vet exakt var de ska hitta rätt filer.
Ett annat effektivt sätt att styra dina statiska filer är att namnge dem baserat på vad de gör. Skapa till exempel en reset.css, en typography.css, en dimensions.css, en colors.css, etc. Det finns för och nackdelar med denna metod, särskilt för CSS. Det håller din CSS inriktad på presentationsregler. Det kommer emellertid sannolikt att kräva att du repeterar väljare över flera filer och öppnar dem för att definiera olika typer av stilregler. Det enda sättet att undvika detta är att bara namnge dina klasser / ID-tal efter stil snarare än semantik, till exempel class = "green-text fem kolumner medellång skugga". Annars kommer du att sluta göra något så här:
I typography.css
.semantisk-widget färg: # 232323; textskugga: 1px 1px #fff; typsnittstorlek: 1.2em; linjehöjd: 1.1em; font-family: sans-serif; typsnitt: 300;
I dimensions.css
.semantisk widget bredd: 20%; marginal: 0 2,5%; vaddering: 10px;
Vilket är naturligtvis inte så torrt som möjligt.
Organisation av mindre applikationer (med färre av dessa "widget" -objekt) kan fortfarande dra nytta av separationen med regeltyp.
Men om du har en applikation som har många olika objekttyper, applikationsområden etc. bör du förmodligen välja att separera dina CSS-filer i områden (den speglingsstrategi vi diskuterade ovan).
Namngivning av JavaScript-filer genom deras funktioner är lite mer genomförbart, men bara om du utnyttjar händelseutlösare (en pub / submodell). Tänk på följande exempel:
Accentsconagua
$ .getJSON ("/ messages / all.json", funktion (data) // gör några saker); Du kanske vill göra en hel del saker i denna återuppringning. Du kanske vill skicka en anmälan till användaren och uppdatera en lista med meddelanden. Om du har dina filer separerade av funktionalitet kan du ha en notifications.js och a messages.js fil som hanterar dessa specifika funktioner. Inuti återkallelsen för detta JSON-ajax-samtal skulle du "publicera" en händelse till resten av programmet. Sedan inuti dina meddelanden och meddelandefiler kan du "prenumerera" på händelsen och svara därefter.
i events.js:
$ .getJSON ("/ messages / all.json", funktion (meddelanden) $ ("body"). trigger ("received_messages", meddelanden);); i messages.js:
$ ("body") på ("received_messages", funktion (händelse, meddelanden) // iterera genom meddelanden och lägg till en lista); i notifications.js
$ ("body"). On ("received_messages", funktion (händelse, meddelanden) // send_notification kan vara en lokal funktion som låter dig skicka meddelanden // till användaren tillsammans med en meddelandetyp, ett heltal I det här fallet kan "1" helt enkelt innebära att meddelandet stämmer som en "succé" alert send_notification ("Succesfully Received Messages!", 1);); Det finns några saker att komma ihåg om dina statiska filer. Den här artikeln förutsätter att du stämmer samman med dina statiska filer på ett lämpligt sätt. Men vad exakt är lämpligt?
Så, varför skulle du göra det, frågar du? För det första att utnyttja webbläsarens cache.
Konkurrens i flygningen tillåter till exempel inte att du utnyttjar webbläsarens cache. Den andra fördelen med detta tillvägagångssätt är bara att ladda vad du behöver. Om du har en hel "admin" sektion som 95% av dina användare aldrig ser, borde de inte behöva ladda ner CSS för den sektionen.
Utveckla en standardsyntax och håll fast vid den.
På samma sätt som CSS bör JavaScript skötas på ett effektivt sätt.
Vinsterna ska alltid hanteras noggrant. om ditt javascript är tillräckligt liten för att motivera sammanfogning till ett enda skript, anser du inte alls för att ladda modulär JavaScript i din slutprodukt.
Såsom kortfattat nämnts ovan, om inte det finns ett försumbart antal användare som träffar en viss sida, lägg inte CSS / JS i dina globala applikationsstatiska filer. Administrativa statiska filer ska också vara separata. Om din ansökan stöder användarkonton, överväga att utesluta de statiska filerna för obehörig (marknadsföring) sidan av programmet. När en användare loggar in, har de redan åtagit sig att delta i vad din ansökan ger. Första intryck är allt och lastning av en massa oanvända CSS och JavaScript kommer bara att försämra prestanda för ett första intryck.
Om du verkligen använder ett ramverk, använd den ramens befintliga struktur. Om din ram inte har en befintlig struktur eller en mycket enkel struktur (Sinatra och CodeIgniter är bra exempel på detta), överväga att spegla strukturen hos andra komponenter i applikationen. Om du börjar från grunden, ta en titt på andra projekt som folk har genomfört i både ramverket du använder och i andra ramar med samma språk. Om du till exempel väljer ramverk på MVC men inte har standardkonfigurationer för placering av dessa bitar är det troligt att det finns en namngivning konvent som använder sökorden Model, View och Controller.
När det gäller det är företagsnivåorganisationen ungefär fyra primära saker:
