Share
Organisasjonen kan gjøre eller ødelegge vedlikeholdet av et program. Med mindre applikasjoner er organisasjonen mer åpenbart tydelig; Men etter hvert som applikasjonen vokser, og etter hvert som antallet applikasjonsutviklere og frontend-ingeniører som produserer kode øker, kan den mer forvirrende organisasjonen bli. I dette innlegget vil vi gå over noen grunnleggende begreper for å holde applikasjoner organisert slik at det å finne relevant kode er en effektiv og systematisk prosess.
JavaScript bør scoped på en effektiv måte.
La oss ta et øyeblikk og vurdere hvordan Rails og Wordpress-lagene organiserer sine prosjekter. Sjansen er, du har sikkert jobbet med en eller den andre av disse. Begge rammeverkene har en angitt standardstruktur.
Når du genererer et Rails-program, håndterer Rails mye av de primære organisatoriske behovene for deg. Fordi den er basert på MVC, inneholder standardoppsettet Rails en mappe med etiketten "app", som inneholder modell / visning / kontrollermapper. Det gir også "helpers" og "mailers", regulatorutvidelsene som hjelper til med å fylle mellom hullene mellom kontroller og modeller.
Rails genererer også noen andre elementer på samme nivå som «app» -mappen, for eksempel konfigurasjon, logging, databaser, midlertidig / caching, tester og noen andre biter. Det som er spesielt interessant for denne diskusjonen er app og offentlige mapper. Den offentlige mappen er der statiske eiendeler blir servert fra, inkludert ikke-dynamiske HTML-, CSS- og JavaScript-filer.
Når du arbeider med Wordpress, er navngivningen og strukturen langt mindre åpenbar.
... programmet er bygget for brukere ...
Konvensjoner blir eksponert ved hjelp av dokumentasjonen. Spesielt utvikler utviklere sannsynligvis innenfor et tema, som ligger i wp-innhold / temaer / katalog. Dette temaet har en rekke filer med spesialnavn, hovedsakelig basert på visninger. EN functions.php fil fungerer som en "controller" av sorter, hvor en utvikler kan sette funksjoner for å skille dem fra visningene. Men Wordpress temaer ofte gjørmete farvannene mellom logikk og presentasjon. For eksempel er databasespørsmål implisitt av filnavn, men blir ofte manipulert ved å endre søket før de går gjennom de returnerte resultatene. Denne manipulasjonen abstrakt ikke på samme måte som en kontroller ville (og selvfølgelig, Wordpress ikke er hvor som helst i nærheten av MVC, så vi kan ikke forvente denne typen organisasjon).
Begge disse rammene er ekstremt populære, og begge bruker sin egen implisitte strukturering. De krever absolutt at utviklere forstår hvordan systemet fungerer for å være effektivt. I våre egne applikasjoner bør vi ivareta dette organisatoriske paradigmet, og skape en systematisk tilnærming til strukturering av applikasjoner. Dette spiller ut veldig forskjellig for hver enkelt applikasjon.
De ovennevnte rammene krever ikke at utviklere definerer strukturen; de er "pre-wired" for å jobbe på en bestemt måte.
En viktig grunn til robuste rammer ofte abstraherer disse konfigurasjonene og gir standardstrukturer, slik at folk vil begynne å utvikle en fellesskapsstandard basert på standardstrukturen.
Ikke ignorere standarder når du organiserer søknaden din!
Hvis du er kjent med Rails, kan du mest sannsynlig se på et Github-depot og vite om det er en Rails-app bare etter mappestrukturen - Rails har en dokumentert standard.
Ikke ignorere standarder når du organiserer søknaden din! Det er høyst sannsynlig at hvis du organiserer et bedriftsnivåprogram, har du å gjøre med modulære, diskrete servicebaserte mini-applikasjoner. For eksempel kan det være tilfelle at du har flere programmer bygget med en eller flere forskjellige rammer, eller de kan bli rullet for hånd og arbeide sammen med hverandre, og utsette APIer som gir kroker for de andre tjenestene. Hver av disse diskrete applikasjonene følger sannsynligvis kravene til rammen den ble bygget på; Disse standardene eksisterer fordi de er måten dette rammene var utformet for å fungere. Hvis du prøver å endre disse standardene i et diskret program, vil du sannsynligvis ende opp sløse mer tid konfigurere enn å faktisk bygge et arbeidsprogram.
I praksis betyr dette at de tingene som blir utsatt fra en tjeneste til en annen, skal fungere på en ensartet måte, og de stykkene som er interne til en tjeneste, bør fungere som det beste for den aktuelle tjenesten, sannsynligvis drevet av uansett rammeverk eller teknologi stabelen som tjenesten går på.
Husk, på slutten av dagen, er applikasjonen bygget for brukere, og brukere vet ikke eller verdsetter separasjonen av de diskrete tjenestene.
De forstår i stedet søknaden og opplevelsen som ett stykke, og det ene stykket vil først og fremst ha nytte av ensartethet på toppnivå.
Så hva må være uniform?
som søknaden vokser ... jo mer forvirrende organisasjon kan bli.
Ruter (URL-strukturer) er en av de viktigste definerende faktorene for hvordan et webprogram fungerer. Det er viktig at rutene dine følger en jevn struktur. For eksempel, når du viser en "brukerkonto" med en nettadresse som / Bruker / 5 hvor 5 er brukerens primærnøkkel heltall-ID, bør du ikke bruke plural for et annet entall objekt, for eksempel / Moduler / 16. I stedet bør det være / Widget / 16. Dette hjelper ikke bare utviklere ved å være konsistente, men gir også klarhet og enhetlighet for brukerne. Det spiller ingen rolle hva du velger for rutestrukturen din så lenge det er konsistent på nivået med brukeren.
Dette er en som er svært viktig for intern utvikling, og det er enda viktigere for programvareprodukt / tjenesteutvikling hvor en API er utsatt for publikum. Hvis API-anropene dine har understreker som ordseparatorer, må du ikke bruke en kamel eller en dash-separert nøkkel i APIen din andre steder. Hvis du bruker ordet "count" for å bety "returnere dette antall objekter", må du ikke bruke noe som "count_per_page" for å bety det samme andre steder i samme (eller en tilhørende) API. Dette er slurvet API-design. Utvikle en standard syntaks og hold deg til det; Legg merke til at dette ofte blir tatt vare på ved velutført ruteutforming i REST APIs.
På et generelt nivå, når du arbeider med "foo widgets" (vilkårlig objekter eller handlinger) i søknaden din, må du sørge for at du bruker samme terminologi på tvers av alle dine applikasjoner. For eksempel, mens det kan være vanlig praksis i Rails å bruke "offentlige" katalogen, har du kontroll over hva som går inne i det.
Ikke bruk en "js" -mappe for en rammeverk og en "skript" -mappe for et annet rammeverk.
Ikke ring datamodeller "orange_items" i ett rammeverk og "OrangeItems" i et annet, med mindre språk eller rammeverk uttrykkelig krever dette for en funksjonell grunn. Selv da, sørg for at det er et konsistent system og "grammatikk", og sørg for at forskjellene mellom de diskrete tjenestene er godt dokumentert og berettiget. Disse typer tegn og enhetlighet vil i stor grad hjelpe forståelsen av klassifikasjoner av objekter over et program.
Speilruter til mapper og filer bidrar sterkt til å holde et program organisert. For eksempel kan du ha mapper for CSS, JavaScript og bilder i dine "offentlige" eller "statiske" mapper. Å lage en struktur av mapper som kartlegger ruter, visninger, kontrollører eller andre lignende strukturer kan bidra til å holde CSS modulert. Du kan deretter bruke et verktøy som CodeKit for å sammenkoble disse filene til en enkelt minifisert fil. Selvfølgelig kan du også ha en global.css for regler som gjelder over hele applikasjonen. Se nedenfor for et eksempel (.rb er for Ruby, men dette kan gå for enhver MVCs rammeorganisasjon).
- root / - app / --- modeller / ---- foo.rb ---- bar.rb ---- baz / ----- widget.rb --- visninger / ---- global. html.erb ---- foo.html.erb ---- bar.html.erb ---- baz / ----- widget.html.erb --- controllers ---- foo.rb - - bar.rb - offentlig - 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 raskt se at det ikke ville være vanskelig å finne bestemte CSS, JavaScript, modeller osv. For en bestemt del av søknaden.
Ruter (URL-strukturer) er en av de viktigste definerende faktorene for hvordan et webprogram fungerer.
Den beste måten å tenke på dette er å skille filene dine til "områder" på nettstedet ditt. For eksempel, kanskje du har et program som inneholder et "admin" -område og et "profil" -område. Du kan opprette en global.css fil for å holde objektene / reglene som gjelder for begge områdene (inkludert tilbakestilling, noen typografiregler, farger osv.) og deretter lage bestemte filer som gjelder for de separate områdene for innholdsformeringsregler som ikke deles. På denne måten, som en utvikler jobber på en bestemt side, vil de bli i en eller to filer, og vil vite nøyaktig hvor de skal finne de riktige filene.
En annen effektiv måte å kontrollere dine statiske filer på er å navngi dem basert på hva de gjør. For eksempel lage en reset.css, en typography.css, en dimensions.css, en colors.css, etc. Det er fordeler og ulemper med denne metoden, spesielt for CSS. Det holder CSS fokusert på presentasjonsregler; Det vil imidlertid trolig kreve at du gjentar selectors over flere filer, gjenåpner dem for å definere forskjellige typer stilregler. Den eneste måten å unngå dette på er å navngi dine klasser / IDer bare etter stil i stedet for semantikk, for eksempel class = "green-text fem-kolonner medium-skygge". Ellers vil du ende opp med å gjøre noe slikt:
I typography.css
.semantisk-widget farge: # 232323; tekstskygge: 1px 1px #fff; fontstørrelse: 1.2em; linjehøyde: 1.1em; font-familie: sans-serif; font-weight: 300;
I dimensions.css
.semantisk-widget bredde: 20%; margin: 0 2,5%; polstring: 10px;
Som selvfølgelig er det ikke så tørt som mulig.
Organisering av mindre applikasjoner (med færre av disse "widget" -objektene) kan fortsatt ha nytte av separasjonen etter regeltype.
Men hvis du har et program som har mange forskjellige objekttyper, applikasjonsområder osv., Bør du sannsynligvis velge å skille CSS-filene dine i områder (speilstrategien vi diskuterte ovenfor).
Det er litt mer mulig å navngi JavaScript-filer etter deres funksjoner, men bare hvis du utnytter hendelsesutløsere (en pub / sub-modell). Vurder følgende eksempel:
Accentsconagua
$ .getJSON ("/ messages / all.json", funksjon (data) // gjør noen ting); Du vil kanskje gjøre ganske mange ting i denne tilbakekallingen. Du vil kanskje sende et varsel til brukeren og oppdatere en liste over meldinger. Hvis du har filene dine skilt av funksjonalitet, kan det hende du har en notifications.js og a messages.js fil som håndterer disse bestemte funksjonene. I tilbakekallingen for denne JSON ajax-samtalen, vil du "publisere" en hendelse til resten av programmet. Deretter inne i meldingene og meldingsfilene dine, kan du "abonnere" på arrangementet og svare på det.
i events.js:
$ .getJSON ("/ messages / all.json", funksjon (meldinger) $ ("body"). trigger ("received_messages", meldinger);); i messages.js:
$ ("body"). på ("received_messages", funksjon (hendelse, meldinger) // iterate gjennom meldinger og legge til en liste); i notifications.js
$ ("body"). på ("mottatt_meldinger", funksjon (hendelse, meldinger) // send_notification kan være en lokal funksjon som lar deg sende meldinger // til brukeren sammen med en varslingstype, et heltall I dette tilfellet kan "1" ganske enkelt bety å formatere varselet som en "suksess" varsel send_notification ("Suksessfully Received Messages!", 1);); Det er noen ting å huske på dine statiske filer. Denne artikkelen antar at du vil sammenkoble dine statiske filer på en passende måte. Men hva er egentlig riktig?
Så hvorfor ville du gjøre dette, spør du? Først og fremst for å utnytte nettleserens cache.
Sammenkobling i fly, for eksempel, tillater deg ikke å utnytte nettleserens cache. Den andre fordelen med denne tilnærmingen er bare å laste inn det du trenger. Hvis du har en hel "admin" -avdeling som 95% av brukerne aldri ser, bør de ikke laste ned CSS for den delen.
Utvikle en standard syntaks og hold deg til den.
I likhet med CSS bør JavaScript skannes på en effektiv måte.
Gevinstene skal alltid håndteres nøye; hvis javascript er liten nok til å rettferdiggjøre sammenkobling til et enkelt skript, må du ikke føle deg presset til å laste modulærisert JavaScript i sluttproduktet.
Som kort nevnt ovenfor, hvis ikke det er et ubetydelig antall brukere som rammer en bestemt side, må du ikke sette CSS / JS i statiske filer i global applikasjon. Administrative statiske filer bør også forbli atskilt. Hvis din søknad støtter brukerkontoer, bør du vurdere å utestille de statiske filene for uautorisert (markedsføring) siden av programmet. Når en bruker logger på, har de allerede gjort en forpliktelse til å ta del i hva søknaden din gir. Førsteinntrykk er alt, og lasting av en haug med ubrukt CSS og JavaScript vil bare degradere ytelsen til et førsteinntrykk.
Hvis du faktisk bruker et rammeverk, bruk det rammets eksisterende struktur. Hvis rammen din ikke har en eksisterende struktur, eller en veldig enkel struktur (Sinatra og CodeIgniter er gode eksempler på dette), bør du vurdere å speile strukturen til andre komponenter i applikasjonen. Hvis du begynner fra grunnen, ta en titt på andre prosjekter folk har fullført i både rammen du bruker og i andre rammer med samme språk. Hvis du for eksempel er valgt rammeverk på MVC, men ikke har standardkonfigurasjoner for plassering av disse bitene, er det sannsynlig at det er en navngivning konvensjon som bruker søkeordene Model, View og Controller.
Når det kommer til det, er organisasjon på organisasjonsnivå omtrent fire primære ting:
