Дизајн иОС архитектуре: Мотивација

Приближимо се теми стварања сопствене архитектуре у овом низу чланака.

Шта је архитектура?

Архитектура је највиши ниво дизајна система.

Дизајн система је начин да се олакша производња кода за апликацију.

Апликација је медиј потребан за испуњавање (пословног) циља.

Могу ли га прескочити?

Чак и када не припремите дизајн система пре него што направите апликацију, још увек морате да размислите пре него што напишете било који код, а то се назива случајним дизајном система, што доводи до случајне архитектуре (АА).

Лако је открити случајну архитектуру:
П: Зашто је наш код тако ружан?
О: Историјски разлози…

Шта ћу добити?

Сврха постављања формалне архитектуре, а не скок у кодирање ствари је успостављање смерница, ограничења и образаца према којима ће код расти.

Замислите да поставите архитектуру као полагање железнице за код који се креће дуж ње као воз.

Зашто бих се обуздао?

Смернице, ограничења и обрасци помажу у:

  • код који следи принцип најмање запрепаштења;
  • разумети како функционише постојећи систем;
  • избегавајте измислити точак;
  • ширити радне идеје у заједници.

Могу ли да користим један од њих са интернета?

Требали бисте научити од тога, али сви они трпе многе проблеме:

  • не пружају стратегије раста;
  • добро прилагођавање само једној величини апликација и тима;
  • случајни ниво апстракције компонената и комуникације;
  • нејасна расподјела улога (гледам вас "Радник");
  • неопростиво и фанатично;)

Да ли имам довољно вештина да га дизајнирам?

Нико нема довољно, али што више имате, лакше је видети светлост на крају тунела.
Ево шта ће вам помоћи:

  • читати старе књиге и беле радове о дизајну и обрасцима система;
  • избегавајте нове чланке који покушавају да вам продају сребрни метак;
  • научите шта за друге делује у производњи;
  • користите друге платформе као извор инспирације;
  • испробајте идеје код куће, ако раде, доведите их на посао;
  • одложите одлуку ако сте у недоумици (у међувремену направите глупу ствар);
  • разговарати о идејама и имплементацијама са другима.

Одакле да почнем?

Увек би требало да почнемо са анализом захтева (као у сваком зрелом подухвату) који потичу од циља.

Функционални захтеви.

У најгорем случају можете добити функционалну спецификацију високог нивоа, попут ове:

  • Апликација за листу за куповину;
  • Способност колаборације на листама;
  • Могућност коришћења без интернетске везе.

У овој фази, бизнис може помислити да су захтеви довољни, а ваша је одговорност да пронађете одговоре на низ питања која се појављују, на пример:

  • Како ће изгледати кориснички интерфејс?
  • Које уређаје апликација мора да подржава?
  • Да ли морам да правим и сервер-страну?

Када не можете да размишљате о другим питањима, време је да пређете на следећу фазу.

Организациони захтеви.

Ако се не ради о греенфиелд пројекту, можда постоји доста ограничења у вашем избору архитектуре, барем покушајте да одговорите на ова питања:

  • Ко је мој тим?
  • Шта очекују од наше архитектуре?
  • Да ли имамо успостављене алате и језике?
  • Можемо ли поново употребити постојећу архитектуру?

Могу ли коначно почети да правим архитектуру?

Да ти то можеш! Постављањем функционалних и организационих захтева заједно можете започети са излагањем својих идеја и на крају саставити формалну Архитектуру! Али то је сасвим другачија прича ...

Могу ли сада отићи кући?

Пре него што своје идеје изнесете у дивљину, предлажем вам да их тестирате на основу опсежног списка који сам саставио ради ваше удобности.

Како се користи контролна листа?

Узмите своју архитектуру кандидата и претварајте се да је њен заговорник одговарањем на питања као што је пробно (замишљајући да порота иОС заједнице помаже).

Хвала вам за читање!

Пошаљите ми на Твиттеру за повратне информације.

Где да кренемо одавде?

Преглед постојећих иОС архитектура.
Преглед МВЦ обрасца.