IOS-i arhitektuuri kujundamine: motivatsioon

Läheneme selles artiklite sarjas oma arhitektuuri loomise teemale.

Mis on arhitektuur?

Arhitektuur on süsteemidisaini kõrgeim tase.

Süsteemi kujundamine on viis rakenduse koodi tootmise hõlbustamiseks.

Rakendus on (äri) eesmärgi saavutamiseks vajalik meedium.

Kas ma saan selle vahele jätta?

Isegi kui te ei valmista süsteemi kujundust enne rakenduse loomist, peate enne koodi kirjutamist siiski mõtlema. Seda nimetatakse juhuslikuks süsteemi kujundamiseks, mis viib juhusliku arhitektuurini (AA).

Juhuslikku arhitektuuri on lihtne tuvastada:
K: Miks meie kood on nii kole?
A: ajaloolised põhjused ...

Mida ma võidan?

Ametliku arhitektuuri seadistamise asemel kodeerimisega tegelemiseks on vaja kehtestada juhised, piirangud ja mustrid, mille järgi kood kasvab.

Mõelge arhitektuuri seadistamisele kui raudtee paigaldamisele koodile, et see liiguks mööda rongi.

Miks ma peaksin end vaos hoidma?

Juhised, piirangud ja mustrid aitavad:

  • kood, mis järgib vähima hämmastuse põhimõtet;
  • aru saada, kuidas olemasolev süsteem töötab;
  • vältige ratta leiutamist;
  • levitada kogukonnas tööideesid.

Kas ma saan mõnda neist Internetist kasutada?

Neilt peaksite õppima, kuid et neil kõigil on palju probleeme:

  • ärge esitage kasvustrateegiaid;
  • sobib hästi ainult ühe suurusega rakenduste ja meeskonna jaoks;
  • komponentide abstraktsiooni ja kommunikatsiooni juhuslik tase;
  • rollide ebamäärane jaotus (ma vaatan sind “töötajana”);
  • andestamatu ja fanaatiline;)

Kas mul on selle kujundamiseks piisavalt oskusi?

Kellelgi pole piisavalt, kuid mida rohkem teil on, seda kergem on tunneli lõpus valgust näha.
Siit saate abi:

  • lugeda vanu raamatuid ja valgeid teoseid süsteemi kujundamise ja mustrite kohta;
  • vältige uusi artikleid, mis üritavad teile hõbekuulit müüa;
  • õppida, mis töötab tootmises teiste jaoks;
  • kasutada inspiratsiooniallikana teisi platvorme;
  • proovige kodus ideid, kui need töötavad, viige need tööle;
  • lükake otsus edasi, kui kahtlete (tehke vahepeal loll asja);
  • arutage teistega ideid ja teostusi.

Kust alustada?

Peaksime alati alustama eesmärkide (nagu iga küpse ettevõtmise puhul) eesmärkide analüüsist, mis tulenevad eesmärgist.

Funktsionaalsed nõuded.

Halvimal juhul võite saada kõrgetasemelise funktsionaalse spetsifikatsiooni, näiteks:

  • Ostunimekirja rakendus;
  • Võimalus nimekirjades koostööd teha;
  • Võimalus kasutada ilma Interneti-ühenduseta.

Selles etapis võib ettevõte arvata, et nõuded on piisavad, ja teie vastutusel on leida vastused tekkinud probleemidele, näiteks:

  • Kuidas KI välja näeb?
  • Milliseid seadmeid rakendus peab toetama?
  • Kas ma pean tegema ka serveripoole?

Kui te ei saa mõelda teistele esitatavatele küsimustele, on aeg liikuda järgmisse etappi.

Organisatsiooninõuded.

Kui see pole haljasala projekt, võib teie arhitektuuri valikul olla palju piiranguid, proovige vähemalt vastata järgmistele küsimustele:

  • Kes on minu meeskond?
  • Mida nad meie arhitektuurilt ootavad?
  • Kas meil on loodud tööriistad ja keeled?
  • Kas me saame olemasolevat arhitektuuri uuesti kasutada?

Kas ma saan lõpuks arhitektuuri tegema hakata?

Jah, sa saad! Funktsionaalseid ja korralduslikke nõudeid kokku pannes saate hakata oma ideid visandama ja seejärel koostama ametliku arhitektuuri! Kuid jutustada on hoopis teine ​​lugu ...

Kas ma võin nüüd koju minna?

Enne oma ideede loodusesse viimist soovitan teil neid testida põhjaliku kontrollnimekirja alusel, mille olen teie mugavuse huvides koostanud.

Kuidas kasutada kontrollnimekirja?

Võtke oma kandidaadiarhitektuur ja teeselge, et olete selle propageerija, vastates küsimustele nagu kohtuprotsessil (iOS-i kogukonna žürii kujutlus aitab).

Aitäh, et lugesite!

Saatke mulle tagasisidet Twitteris.

Kuhu siit edasi minna?

Ülevaade olemasolevatest iOS-i arhitektuuridest.
Ülevaade MVC mustrist.