„IOS“ architektūros projektavimas: motyvacija

Pažvelkime į savo straipsnių ciklą apie savo architektūros kūrimą.

Kas yra architektūra?

Architektūra yra aukščiausias sistemos projektavimo lygis.

Sistemos dizainas yra būdas palengvinti programos kodo gamybą.

Paraiška yra terpė, reikalinga (verslo) tikslui pasiekti.

Ar galiu tai praleisti?

Net kai neparengiate sistemos projekto prieš kurdami programą, vis tiek turite galvoti prieš rašydami kodą. Tai vadinama atsitiktiniu sistemos dizainu, kuris lemia atsitiktinę architektūrą (AA).

Nesunku aptikti atsitiktinę architektūrą:
Kl .: Kodėl mūsų kodas yra toks bjaurus?
A: Istorinės priežastys ...

Ką aš gausiu?

Formalios architektūros sukūrimo, o ne perėjimo prie kodavimo, tikslas yra nustatyti gaires, apribojimus ir modelius, pagal kuriuos kodas augs.

Pagalvokite apie architektūros nustatymą kaip geležinkelio tiesimą, kad kodas judėtų juo kaip traukinys.

Kodėl turėčiau save suvaržyti?

Gairės, apribojimai ir modeliai padeda:

  • kodas, vadovaujantis mažiausio nustebimo principu;
  • suprasti, kaip veikia esama sistema;
  • venkite išradinėti ratą;
  • skleisti darbines idėjas bendruomenėje.

Ar galiu naudoti vieną iš interneto?

Turėtumėte pasimokyti iš tų, tačiau jie visi kenčia nuo daugybės problemų:

  • nepateikite augimo strategijų;
  • gerai tinka tik vieno dydžio programoms ir komandai;
  • atsitiktinis komponentų abstrakcijos ir komunikacijos lygis;
  • neaiškus vaidmenų pasiskirstymas (aš žiūriu į tave „darbuotojas“);
  • atlaidus ir fanatiškas;)

Ar turiu pakankamai įgūdžių ją projektuoti?

Niekam neužtenka, bet kuo daugiau turite, tuo lengviau pamatyti šviesą tunelio gale.
Štai kas jums padės:

  • skaityti senas knygas ir baltuosius dokumentus apie sistemos dizainą ir modelius;
  • venkite naujų gaminių, bandančių jums parduoti sidabrinę kulką;
  • sužinoti, kas gamyboje tinka kitiems;
  • naudoti kitas platformas kaip įkvėpimo šaltinį;
  • išbandykite idėjas namuose, jei jos veikia, atsineškite jas į darbą;
  • atidėti sprendimo priėmimą, jei kyla abejonių (tuo tarpu padaryk kvailą);
  • aptarti idėjas ir įgyvendinimą su kitais.

Nuo ko pradėti?

Visada turime pradėti analizuoti reikalavimus (kaip ir kiekviename brandžiame darbe), kurie kyla iš tikslo.

Funkciniai reikalavimai.

Blogiausiu atveju galite gauti aukšto lygio funkcines specifikacijas, tokias kaip:

  • Pirkinių sąrašo programa;
  • Gebėjimas bendradarbiauti sudarinėjant sąrašus;
  • Galimybė naudoti be interneto ryšio.

Šiame etape verslas gali pamanyti, kad reikalavimai yra pakankami, ir jūs esate atsakingi už tai, kad rastumėte atsakymus į kylančių klausimų spąstus, pavyzdžiui:

  • Kaip atrodys vartotojo sąsaja?
  • Kokius įrenginius programa turi palaikyti?
  • Ar aš taip pat turiu kurti serverio pusę?

Kai negalvojate apie kitus užduodamus klausimus, laikas pereiti į kitą etapą.

Organizaciniai reikalavimai.

Jei tai nėra plyno lauko projektas, gali būti, kad pasirenkate daug architektūros apribojimų, bent pabandykite atsakyti į šiuos klausimus:

  • Kas yra mano komanda?
  • Ko jie tikisi iš mūsų architektūros?
  • Ar mes turime nusistovėjusias priemones ir kalbas?
  • Ar galime pakartotinai panaudoti esamą architektūrą?

Ar galiu pagaliau pradėti kurti architektūrą?

Taip tu gali! Sujungę funkcinius ir organizacinius reikalavimus, galite pradėti išdėstyti savo idėjas ir galiausiai sudaryti oficialią architektūrą! Bet tai jau visai kita istorija, kurią reikia papasakoti ...

Ar galiu grįžti namo dabar?

Prieš pradėdami įgyvendinti savo idėjas, siūlau jas išbandyti nepalankiausiomis sąlygomis pagal išsamų kontrolinį sąrašą, kurį aš sudariau jūsų patogumui.

Kaip naudotis kontroliniu sąrašu?

Paimkite savo kandidato architektūrą ir apsimeskite jos šalininku atsakydami į tokius klausimus, kaip teisiamajame posėdyje (įsivaizduojama „iOS“ bendruomenės žiuri pagalba).

Ačiū, kad skaitėte!

Praneškite man apie tai „Twitter“ ir gaukite atsiliepimų.

Kur toliau eiti?

Esamų „iOS“ architektūrų apžvalga.
MVC modelio apžvalga.