Design af iOS-arkitektur: Motivation

Lad os nærme os emnet med at skabe egen arkitektur i denne serie af artikler.

Hvad er arkitektur?

Arkitektur er det højeste niveau i et systemdesign.

Systemdesign er en måde at lette produktionen af ​​kode til en applikation.

En applikation er et medium, der er nødvendigt for at opfylde et (forretnings) mål.

Kan jeg springe det over?

Selv når du ikke forbereder systemdesign, før du opretter appen, skal du stadig tænke over, før du skriver nogen kode, og det kaldes utilsigtet systemdesign, hvilket fører til utilsigtet arkitektur (AA).

Det er let at opdage utilsigtet arkitektur:
Spørgsmål: Hvorfor vores kode er så grim?
A: Historiske grunde ...

Hvad får jeg?

Formålet med at oprette en formel arkitektur snarere end at springe ind i kodning er at etablere retningslinjer, begrænsninger og mønstre, i henhold til hvilke koden vil vokse.

Tænk på at oprette arkitektur som at lægge en jernbane for en kode til at bevæge sig langs den som et tog.

Hvorfor skulle jeg holde mig tilbage?

Retningslinjer, begrænsninger og mønstre hjælper med at:

  • kode efter princippet om mindst forundring;
  • forstå, hvordan et eksisterende system fungerer;
  • undgå at opfinde hjulet igen;
  • sprede arbejdsidéer i samfundet.

Kan jeg bruge en af ​​dem fra internettet?

Du skal lære af dem, men at de alle lider af mange problemer:

  • giver ikke vækststrategier;
  • god pasform til kun en størrelse af apps og team;
  • tilfældigt niveau af komponenter abstraktion og kommunikation;
  • vag rollefordeling (jeg ser på dig ”Arbejder”);
  • utilgivende og fanatisk;)

Har jeg nok færdigheder til at designe det?

Ingen har nok, men jo mere du har, jo lettere er det at se lyset i slutningen af ​​en tunnel.
Her er hvad der hjælper dig:

  • læse gamle bøger og hvidbøger om systemdesign og mønstre;
  • undgå nye artikler, der prøver at sælge dig en sølvkugle;
  • lære, hvad der fungerer for andre i produktionen;
  • bruge andre platforme som en kilde til inspiration;
  • prøv idéer derhjemme, hvis de arbejder, tag dem med på arbejde;
  • udsæt beslutningen, hvis du er i tvivl (lav en dum ting i mellemtiden);
  • diskutere ideer og implementeringer med andre.

Hvor skal jeg starte?

Vi bør altid starte med at analysere krav (som i enhver moden bestræbelse), der kommer fra målet.

Funktionelle krav.

I værste tilfælde kan du få en funktionel specifikation på højt niveau, som denne:

  • Ansøgning om indkøbsliste;
  • Evne til at samarbejde på lister;
  • Mulighed for brug uden internetforbindelse.

På dette tidspunkt kan virksomheden mene, at kravene er tilstrækkelige, og det er dit ansvar at finde svar på den sværm af spørgsmål, der opstår, for eksempel:

  • Hvordan ser UI ud?
  • Hvilke enheder appen skal understøtte?
  • Skal jeg også lave serversiden?

Når du ikke kan tænke på andre spørgsmål, du skal stille, er det tid til at gå videre til næste trin.

Organisatoriske krav.

Hvis det ikke er et greenfield-projekt, kan der være masser af begrænsninger for dit arkitekturvalg, prøv i det mindste at besvare disse spørgsmål:

  • Hvem er mit team?
  • Hvad forventer de af vores arkitektur?
  • Har vi etablerede værktøjer og sprog?
  • Kan vi genbruge en eksisterende arkitektur?

Kan jeg endelig begynde at lave arkitektur?

Ja du kan! Ved at sætte funktionelle og organisatoriske krav sammen, kan du begynde at skitsere dine ideer og derefter til sidst komponere en formel arkitektur! Men det er en helt anden historie at fortælle ...

Kan jeg gå hjem nu?

Inden du tager dine ideer ud i naturen, foreslår jeg, at du stresstest dem mod en omfattende tjekliste, som jeg har udarbejdet for nemheds skyld.

Hvordan bruges tjeklisten?

Tag din kandidatarkitektur, og foregiv at være dens talsmand ved at besvare spørgsmål som til retssag (forestille sig, at en jury af iOS-samfund hjælper).

Tak fordi du læste!

Send mig en besked på Twitter for feedback.

Hvor skal jeg hen herfra?

Oversigt over eksisterende iOS-arkitekturer.
Gennemgang af MVC-mønsteret.