Designe iOS-arkitektur: Motivasjon

La oss nærme oss temaet å lage egen arkitektur i denne artikkelserien.

Hva er arkitektur?

Arkitektur er det høyeste nivået av en systemdesign.

Systemdesign er en måte å forenkle produksjon av kode for en applikasjon.

En applikasjon er et medium som trengs for å oppfylle et (forretnings) mål.

Kan jeg hoppe over det?

Selv når du ikke forbereder systemdesign før du lager appen, må du fortsatt tenke deg om før du skriver noen kode, og dette kalles tilfeldig systemdesign, noe som fører til utilsiktet arkitektur (AA).

Det er lett å oppdage utilsiktet arkitektur:
Spørsmål: Hvorfor koden vår er så stygg?
A: Historiske grunner ...

Hva vil jeg få?

Hensikten med å sette opp en formell arkitektur i stedet for å hoppe inn i koding, er å etablere retningslinjer, begrensninger og mønstre som koden kommer til å vokse etter.

Tenk på å sette opp arkitektur som å legge en jernbane for en kode for å bevege seg langs den som et tog.

Hvorfor skulle jeg holde meg igjen?

Retningslinjer, begrensninger og mønstre hjelper til:

  • kode etter prinsippet om minst forundring;
  • forstå hvordan et eksisterende system fungerer;
  • unngå å finne opp hjulet på nytt;
  • spre arbeidsideer i samfunnet.

Kan jeg bruke en av dem fra internett?

Du bør lære av dem, men at de alle lider av mange problemer:

  • ikke gi vekststrategier;
  • god passform for bare en størrelse på apper og team;
  • tilfeldig nivå av komponenter abstraksjon og kommunikasjon;
  • vag rollefordeling (jeg ser på deg "Arbeider");
  • utilgivende og fanatisk;)

Har jeg nok ferdigheter til å designe det?

Ingen har nok, men jo mer du har, jo lettere er det å se lyset i enden av en tunnel.
Dette er hva som vil hjelpe deg:

  • lese gamle bøker og meldinger om systemdesign og mønstre;
  • unngå nye artikler som prøver å selge deg en sølvkule;
  • lære hva som fungerer for andre i produksjonen;
  • bruke andre plattformer som inspirasjonskilde;
  • prøv ideer hjemme, hvis de jobber, ta dem med på jobb;
  • utsetter beslutningen hvis du er i tvil (gjør en dum ting i mellomtiden);
  • diskutere ideer og implementeringer med andre.

Hvor skal jeg starte?

Vi bør alltid starte med å analysere krav (som i enhver moden forsøk) som kommer fra målet.

Funksjonelle krav.

I verste fall kan du få en funksjonell spesifikasjon på høyt nivå, som denne:

  • Søknad om handleliste;
  • Evne til å samarbeide om lister;
  • Mulighet for bruk uten internettforbindelse.

På dette stadiet kan virksomheten mene at kravene er tilstrekkelige, og det er ditt ansvar å finne svar på svermen av spørsmål som dukker opp, for eksempel:

  • Hvordan vil UI se ut?
  • Hvilke enheter appen må støtte?
  • Må jeg lage serversiden også?

Når du ikke kan tenke på andre spørsmål du kan stille, er det på tide å gå videre til neste trinn.

Organisasjonskrav.

Hvis det ikke er et greenfield-prosjekt, kan det være mange begrensninger for arkitekturvalget ditt, prøv i det minste å svare på disse spørsmålene:

  • Hvem er teamet mitt?
  • Hva forventer de av vår arkitektur?
  • Har vi etablerte verktøy og språk?
  • Kan vi gjenbruke en eksisterende arkitektur?

Kan jeg endelig begynne å lage arkitektur?

Ja det kan du! Ved å sette funksjonelle og organisatoriske krav sammen, kan du begynne å skissere ideene dine og deretter til slutt komponere en formell arkitektur! Men det er en helt annen historie å fortelle ...

Kan jeg dra hjem nå?

Før du tar ideene dine ut i naturen, foreslår jeg at du stresstest dem mot en omfattende sjekkliste jeg har satt sammen for enkelhets skyld.

Hvordan bruker jeg sjekklisten?

Ta kandidatarkitekturen din, og later som hun er talsmann ved å svare på spørsmål som på prøve (å forestille deg at en jury av iOS-samfunnet hjelper).

Takk for at du leser!

Send meg en melding på Twitter for tilbakemelding.

Hvor skal jeg dra herfra?

Oversikt over eksisterende iOS-arkitekturer.
Gjennomgang av MVC-mønsteret.