- Programinės įrangos projektavimas apima viską nuo reikalavimų apibrėžimo iki architektūros, duomenų modelio ir sąsajos, ir yra labai svarbus kuriant patikimas ir prižiūrimas sistemas.
- Tradicinis krioklio gyvavimo ciklas apima analizę, projektavimą, programavimą, testavimą, diegimą ir priežiūrą, nors šiandien jis egzistuoja kartu su evoliucine, spirale ir Agile metodikomis.
- Pasirinkus gerą architektūrą (sluoksnius, šešiakampę, mikropaslaugas, MVC ir kt.) ir taikant projektavimo šablonus kartu su tokiais principais kaip KISS, DRY, YAGNI ir rūpesčių atskyrimas, pagerėja programinės įrangos kokybė ir evoliucija.
- Šiuolaikiniai įrankiai ir metodai be kodo leidžia greičiau projektuoti ir kurti, tačiau vis tiek reikia atidžiai planuoti struktūrą, srautus ir verslo taisykles.
Programinės įrangos kūrimas yra daug daugiau nei kelių kodo eilučių rašymas: tai menas paversti verslo idėjas patikimomis, prižiūrimomis ir patogiomis naudoti sistemomis. Už kiekvienos programos, kuri veikia kaip laikrodis, slypi daugybė išankstinio darbo, apimančio analizę, architektūrą, detalų projektavimą ir geriausios praktikos rinkinį, kuris lemia skirtumą tarp patikimo produkto ir tokio, kuris yra pilnas pataisų.
Jei kada susimąstėte, kodėl kai kurios programos yra intuityvios ir stabilios, o kitos užstringa vos tik jas išjungus, atsakymas beveik visada slypi tame, kaip jos buvo sukurtos. Nuo reikalavimų apibrėžimo iki architektūros pasirinkimo, įskaitant projektavimo šablonus, paprastumo principus ir kūrimo metodikas, viskas pagerina (arba pablogina) galutinio rezultato kokybę.
Ką iš tikrųjų reiškia programinės įrangos dizainas?
Kalbėdami apie programinės įrangos projektavimą, turime omenyje sistemos vidinės struktūros planavimo procesą , apibrėžiant, kaip tvarkomi duomenys, kokius komponentus jie turės, kaip jie bendrauja tarpusavyje ir kaip tenkinami funkciniai ir nefunkciniai reikalavimai. Praktiškai tai yra išsamus techninis planas, kuriuo bus vadovaujamasi vėlesniame programavime.
Šis dizainas neapsiriboja vien techniniais aspektais: jis taip pat apima, kaip vartotojas sąveikaus su sistema , kaip informacija bus pateikiama sąsajoje, kokie naršymo srautai bus prieinami ir kokia patirtis yra numatyta. Todėl programinės įrangos dizainas apima architektūrą, duomenų modelius, algoritmus, vartotojo sąsają (UI) ir vartotojo patirtį (UX).
Įmonėms dizainas yra labai svarbus, nes leidžia kurti individualią programinę įrangą, pritaikytą konkretiems poreikiams , o tai ypač svarbu skaitmeniniame pasaulyje, kur generiniai produktai dažnai neatitinka lūkesčių. Šio etapo praleidimas arba supaprastinimas paprastai lemia išlaidų viršijimą, vėlavimus ir funkcijas, kurios neatitinka lūkesčių.
Praktiškai tai reiškia, kad aukšto lygio idėjos paverčiamos aiškiomis ir įgyvendinamomis techninėmis instrukcijomis kūrimo komandoms. Kuo geresnis dizainas, tuo lengviau bus programuoti, testuoti, prižiūrėti ir tobulinti programą.
Preliminarus etapas: prieš projektuojant, įvertinkite projekto kontekstą
Prieš pradedant visapusiškai žengti į klasikinį kūrimo ciklą, būtina skirti laiko preliminariam problemos ir tikslų apibrėžimo etapui . Šiame etape sistema dar nėra išsamiai suprojektuota, tačiau aiškiai nurodoma, ko siekiama ir kodėl.
Šiame etape dokumentuojamos pradinės programinės įrangos specifikacijos , atskiriant funkcinius reikalavimus (ką sistema turi atlikti) ir nefunkcinius reikalavimus (našumą, saugumą, naudojimo patogumą, technologinius apribojimus ir kt., kurie nėra pasirenkami, bet jiems teikiama skirtinga prioritetinė tvarka).
Įprasta priemonė yra „MoSCoW“ klasifikacija, kurioje kiekviena funkcija žymima kaip „ Būtina“, „Turėtų būti“, „Galėtų būti“ arba „Neturėsime“ . Tai padeda suderinti lūkesčius su klientu, derėtis dėl apimties ir išvengti įprasto nesibaigiančio „būtinų“ elementų sąrašo, kuris vėliau stabdo projektą.
Lygiagrečiai programinė įranga yra kontekstualizuojama: kokią problemą ji išsprendžia, kokią naudą ji atneš , kas bus pagrindiniai naudotojai, su kokiomis kitomis sistemomis ji bus integruojama ir kokie aplinkos ar verslo apribojimai turi įtakos projektui (reglamentai, terminai, biudžetas, turima infrastruktūra ir kt.).
Programinės įrangos gyvavimo ciklo etapai krioklio modelyje
Vienas iš klasikinių kūrimo modelių yra krioklio modelis , kuris gyvavimo ciklo fazes pateikia linijine seka. Nors dabar naudojame daugiau iteracinių metodų, ši struktūra išlieka labai naudinga norint suprasti visą programinės įrangos kūrimo procesą.
1. Reikalavimų analizė
Analizės etapas susideda iš kruopštaus reikalavimų, kuriuos programa turi atitikti, surinkimo, išaiškinimo ir dokumentavimo. Šiame etape apibrėžiama taikymo sritis (kontekstas, kuriame veiks programinė įranga), sistemos tikslas, jos apimtis ir sąveika su aplinka.
Išsamiai aprašomos sistemos atliekamos funkcijos , taip pat ja besinaudojančių vartotojų tipai, techniniai ar teisiniai apribojimai, priklausomybės nuo kitų sistemų, našumo reikalavimai (reakcijos laikas, vienu metu veikiančių vartotojų pajėgumas, duomenų kiekis) ir pagrindinės verslo taisyklės.
Taip pat nustatomos vartotojo sąsajos specifikacijos , bent jau elgsenos lygmeniu: kokie ekranai ar rodiniai bus prieinami, kokie pagrindiniai vartotojo srautai bus stebimi ir kaip įvedami bei rodomi duomenys. Pastovumo lygmeniu apibrėžiami duomenų bazės reikalavimai ir išorinės integracijos.
Klaida šiame etape gali lemti labai brangų pakartotinį darbą vėlesniuose etapuose – tiek laiko, tiek pinigų atžvilgiu. Todėl labai svarbu kruopščiai apgalvoti detales, nuolat jas derinti su klientu ir užtikrinti, kad viskas būtų puikiai dokumentuota ir suderinta.
2. Projektavimas: nuo reikalavimų iki techninio brėžinio
Nustačius reikalavimus, prasideda projektavimo etapas, kurio metu apibrėžiama bendra sistemos architektūra ir vidinė struktūra . Tai apima sprendimą, kurie komponentai bus įtraukti, kaip jie bus organizuoti, kaip jie bendraus tarpusavyje ir kokios technologijos bus naudojamos.
Projektavimas apima duomenų struktūras, algoritmus ir elgseną, būtinus reikalavimams įvykdyti, atsižvelgiant į analizėje nustatytus apribojimus. Jis taip pat sudaro pamatus įgyvendinimui, parengiant aiškią dokumentaciją su veikimo instrukcijomis kūrėjams.
Šiame etape apibrėžiama sistemos architektūra: kokie programinės įrangos moduliai egzistuos, kokias sąsajas jie siūlys , kokie bus jų ryšiai ir kokias pareigas kiekvienas prisiims. Remiantis tuo, pasirenkami projektavimo modeliai, architektūros stiliai ir konkrečios technologijos (sisteminės sistemos, duomenų bazės, vykdymo aplinkos ir kt.).
Norint pavaizduoti ir pagrįsti projektą, galima naudoti formalias kalbas ir diagramas , tokias kaip UML klasių diagramos, veiklos diagramos, Ganto tipo srautų schemos, apribojimų kalbos, tokios kaip OCL, arba dar labiau specializuotus modelius (pavyzdžiui, Petri tinklus), kai reikia modeliuoti lygiagretumą ar sudėtingus srautus.
Svarbu suprasti, kad, skirtingai nei reikalavimų analizė, dizainą iš tiesų lemia pasirinktos technologijos . Pavyzdžiui, sprendimas naudoti šešiakampę architektūrą, mikropaslaugas ar monolitinį metodą tiesiogiai veikia kodo struktūrą ir atsakomybių paskirstymą.
3. Programavimas arba įgyvendinimas
Kai planai bus baigti rengti, laikas rašyti kodą. Programavimas apima projekto pavertimą funkciniu įgyvendinimu , atsižvelgiant į architektūrinius sprendimus, sutartus modelius ir komandos stiliaus konvencijas.
Šiame etape paprastai naudojamos integruotos kūrimo aplinkos (IDE), tokios kaip „Visual Studio Code“, „IntelliJ“ ar panašios , kurios apjungia redaktorių, kompiliatorių, kūrimo įrankius ir derinimo įrankį. Šios aplinkos palengvina ankstyvą sintaksės klaidų, pasikartojančio kodo ar nenaudojamų kintamųjų aptikimą, taip pagerindamos produktyvumą ir kokybę.
Programuojant gera praktika atlikti pradinį pagrindinį derinimą , ištaisyti akivaizdžias klaidas ir užtikrinti, kad kodo vienetai (metodai, klasės, moduliai) atliktų būtent tai, ką turėtų. Tinkamas techninių sprendimų ir kiekvienos dalies funkcionalumo dokumentavimas yra labai svarbus, kad kiti kūrėjai galėtų tęsti darbą vėliau.
Kad ir kokie nepriekaištingi būtų analizės ir projektavimo etapai, prastai įgyvendintas kodas arba kodas su loginėmis klaidomis gali sugadinti visą projektą. Todėl programavimą reikia papildyti geros kokybės praktika, automatizuotu testavimu ir kolegų kodo peržiūra .
4. Testavimas ir patikra
Įdiegus kodą, laikas patikrinti, ar sistema veikia taip, kaip tikėtasi. Testavimo etape daugiausia dėmesio skiriama programinės įrangos atitikties pradžioje apibrėžtiems reikalavimams patvirtinimui : ne tik tam, kad ji „neužstrigtų“, bet ir kad ji atliktų tiksliai tai, ką žadėjo.
Šiame etape pirmiausia aptinkamos logikos arba konceptualios klaidos , kurios yra subtilesnės nei įprastos kompiliavimo klaidos. Sukurti ir atlikti vienetų, integracijos, sistemos ir našumo testai, o prireikus – priėmimo testai su klientu arba galutiniais vartotojais.
Apie bet kokį netikėtą elgesį ar neatitikimus specifikacijoms pranešama kūrėjams, kurie privalo surasti ir ištaisyti priežastį. Šis testavimo, aptikimo, taisymo ir pakartotinio testavimo ciklas kartojamas tol, kol pasiekiamas priimtinas kokybės lygis, kad programinę įrangą būtų galima paleisti į gamybą.
5. Diegimas arba gamybos paleidimas
Kai sistema praeina reikiamus bandymus, programinė įranga įdiegiama ir pradeda savo faktinį veikimo laiką . Diegimas gali reikšti skirtingus dalykus, priklausomai nuo programos tipo.
Jei kalbame apie komercinį produktą, kuris bus parduodamas arba platinamas laisvai, diegimas paprastai sutampa su oficialiu pateikimu rinkai . Įmonei pritaikyto kūrimo atveju tai reiškia diegimą kliento aplinkoje ir galutinį bandymą realiomis sąlygomis.
6. Priežiūra ir evoliucija
Patekusi į gamybos etapą, programinė įranga pereina į nuolatinio gyvavimo ciklo etapą, kuriame tampa būtina ištaisyti problemas, atnaujinti ir tobulinti funkcijas, kad ji ir toliau teiktų vertę laikui bėgant.
Priežiūra paprastai skirstoma į dvi pagrindines kategorijas: korekcinę arba įprastinę priežiūrą , kuri skirta taisyti klaidas, kurios nebuvo aptiktos testavimo metu arba atsirado naudojant sistemą nenumatytuose kontekstuose; ir evoliucinę priežiūrą , kuri įdiegia naujas galimybes arba pritaiko programinę įrangą prie verslo pokyčių.
Kiekvienai tokio tipo intervencijai gali prireikti naujų mini analizės, projektavimo, kūrimo ir testavimo etapų . Pernelyg griežtuose modeliuose grįžti į ciklą yra sunku ir brangu, todėl projektai vėluoja ir nukrypsta nuo sutartų terminų.
Kiti vystymosi modeliai: evoliucinis, spiralinis ir Agile
Krioklio modelis nėra vienintelis būdas organizuoti procesą. Yra metodų, kurie teikia pirmenybę iteracijai, nuolatiniam pritaikymui ir bendradarbiavimui su klientu, siekiant sumažinti riziką ir sutrumpinti grįžtamojo ryšio ciklus.
Evoliucinis modelis ir prototipų kūrimas
Evoliucinis modelis pristato prototipo koncepciją kaip supaprastintą sistemos versiją, kuri klientui pateikiama anksti, siekiant gauti greitą grįžtamąjį ryšį. Ji nebūtinai turi būti visiškai funkcionali; ji tiesiog turi leisti vizualizuoti sąsają arba tam tikras pagrindines funkcijas.
Įprastas ciklas apima prototipo sukūrimą, jo pristatymą, atsiliepimų rinkimą ir reikiamų pakeitimų įdiegimą. Tai kartojama tol, kol pasiekiamas pakankamas brandos lygis galutiniam įgyvendinimui atlikti.
Prototipas gali būti toks paprastas, kaip statinis ekranų maketas, tačiau jis vis tiek naudingas norint patvirtinti funkcinius ir dizaino reikalavimus prieš parašant nė vieną gamybinio kodo eilutę. Tai tiesiogiai nepagerina programavimo kokybės, kuri ir toliau priklausys nuo geriausios komandos praktikos.
Spiralinis modelis
Spiralinis modelis pateikia kūrimą kaip pasikartojantį fazių (planavimo, analizės, projektavimo, įgyvendinimo, testavimo) ciklą, kurie vykdomi keliais etapais, kurių kiekvienas yra detalesnis ir funkcionalesnis nei ankstesnis.
Ryškiausias jo bruožas yra aiškus rizikos vertinimas kiekvienoje iteracijoje . Prieš žengiant toliau, nustatomos ir analizuojamos techninės, verslo ir planavimo rizikos bei priimami sprendimai dėl jų mažinimo. Dėl šios priežasties jis kartais laikomas „metamodeliu“, į kurį galima įtraukti kitus metodus.
Lanksčios metodologijos
Agile filosofija yra daugiau nei konkretus modelis – tai principų ir praktikų rinkinys, kuriuo siekiama laipsniškai kurti vertę , prisitaikyti prie pokyčių ir palaikyti nuolatinį bendradarbiavimą su klientu.
Lankstaus kūrimo kontekste programinė įranga kuriama trumpais iteracijų etapais (sprintais), kurių metu suprojektuojamas, išvystomas, išbandomas ir pristatomas nedidelis, funkcinis produkto priedas. Klientas mato ankstyvus rezultatus, gali nustatyti prioritetus ir peradresuoti darbą pagal savo realius poreikius, o kūrimo komanda turi didesnę autonomiją.
Nors dizainas išlieka pagrindiniu elementu, pastebima tendencija taikyti evoliucinį projektavimo metodą : apibrėžiama pradinė architektūra, kuri yra pakankamai tvirta, kad būtų galima pradėti, o vėliau tobulinama ir plečiama atsirandant naujiems reikalavimams arba patvirtinant naudojimo hipotezes.
Programinės įrangos architektūra: sistemos skeletas
Programinės įrangos architektūrą galima suprasti kaip aukšto lygio sistemos struktūrą : pagrindinius ją sudarančius elementus, jų viešąsias sąsajas ir ryšius tarp jų. Remiantis tokiais apibrėžimais kaip Programinės įrangos inžinerijos instituto apibrėžimas, architektūra apibūdina sistemos struktūras, jas sudarančius elementus, jų matomas savybes ir ryšius tarp jų.
Ši architektūrinė vizija atlieka keletą funkcijų. Viena vertus, ji leidžia kūrėjams suprasti, kaip kiekviena dalis dera prie visumos (moduliai, sąsajos, komunikacijos mechanizmai, priklausomybės). Kita vertus, ji tarnauja kaip bendra nuoroda koordinuojant techninius ir projektavimo sprendimus viso programinės įrangos kūrimo gyvavimo ciklo metu.
Be to, gera architektūra padeda sistemai pasiekti pageidaujamų kokybės savybių : saugumo, mastelio keitimo, našumo , priežiūros, diegimo paprastumo ir kt. Priimant architektūrinius sprendimus neatsižvelgiant į šiuos veiksnius, sistemos dažnai tampa sunkiai tobulinamos ir trapios pokyčių akivaizdoje.
Skirtumas tarp programinės įrangos architektūros ir dizaino
Nors šie terminai kartais vartojami pakaitomis, programinės įrangos architektūra ir projektavimas veikia skirtingais lygmenimis. Architektūra veikia abstraktesnėje plotmėje , apibrėždama bendrą sistemos struktūrą, pagrindinius jos komponentus, jų atsakomybes ir ryšius tarp jų.
Kita vertus, programinės įrangos projektavimas gilinasi į technines detales, būtinas kiekvienam komponentui įdiegti : konkrečius algoritmus, vidines duomenų struktūras, klasių organizavimą, tikslias sąsajas tarp modulių, klaidų tvarkymą ir kt.
Gera analogija yra pastato statyba: architektūra apibrėžia grindų, kolonų, konstrukcinių medžiagų išdėstymą ir bendrą erdvių naudojimą; detalusis projektas apima įrengimą, apdailą, baldus ir konkrečias kiekvieno kambario detales. Abu šie aspektai yra būtini norint pasiekti galutinį rezultatą, tačiau jie veikia skirtingu mastu ir laiku.
Pagrindiniai programinės įrangos architektūros tipai
Priklausomai nuo projekto tipo, komandos dydžio ir verslo reikalavimų, gali būti naudojami skirtingi architektūros stiliai . Kiekvienas iš jų turi privalumų ir trūkumų, kuriuos reikėtų suprasti, kad būtų išvengta netinkamų sprendimų.
„Spagečių“ architektūra
Sistemos, kuriose pateikimo, verslo ir duomenų logika yra sujungtos be aiškaus atskyrimo, šnekamojoje kalboje vadinamos „spagečių“ architektūra . Šis architektūros tipas dažnai sutinkamas senesnėse programose arba projektuose, kurie augo be rimto architektūrinio planavimo.
Rezultatas – painus kodo raizginys, persmelktas kryžminių priklausomybių, kur net ir maži pakeitimai apima daugybės sričių modifikavimą , todėl priežiūra tampa košmaru. Tai puikus pavyzdys, ko siekia išvengti šiuolaikinės sluoksniuotos arba domenų pagrindu sukurtos architektūros.
Sluoksniuota architektūra
Sluoksniuota architektūra atsirado būtent tam, kad kovotų su šiuo chaosu. Ji sistemą padalija į aiškiai apibrėžtus sluoksnius , kurių kiekvienas atsakingas už konkretaus tipo užduotį: pateikimą (vartotojo sąsają), verslo logiką, prieigą prie duomenų ir kt.
Segmentuojant atsakomybes, vieno sluoksnio pakeitimai turi mažesnį poveikį kitiems . Pavyzdžiui, galite modifikuoti informacijos pateikimą nepaveikdami verslo logikos arba pakeisti duomenų bazės variklį, išlaikydami verslo sluoksnį nepažeistą.
Šešiakampė architektūra
Šešiakampė architektūra (dar žinoma kaip prievadai ir adapteriai) siekia visiškai izoliuoti verslo logiką nuo likusios infrastruktūros . Domeno branduolys teikia prievadus (sąsajas), o aplink jį yra sujungti adapteriai duomenų bazėms, išorinėms API, vartotojo sąsajoms ir kt.
Šis metodas leidžia keisti išorines technologijas (mokėjimo teikėją, pranešimų sistemą, žiniatinklio sąsają) nereikalaujant visiškai perrašyti pagrindinės programos dalies . Adapterius galima pakeisti arba modifikuoti nepaveikiant srities, taip padidinant sistemos testavimo galimybes ir ilgaamžiškumą.
MVC (Model-View-Controller) architektūra
MVC architektūros modelis padalija programą į tris komponentus: modelį, rodinį ir valdiklį . Modelis tvarko duomenis ir verslo taisykles, rodinys tvarko pateikimą, o valdiklis veikia kaip tarpininkas, priimantis vartotojų užklausas, koordinuojantis operacijas ir nusprendžiantis, kurį rodinį rodyti.
Šis atskyrimas leidžia vartotojo sąsajai vystytis nepriklausomai nuo verslo logikos. Pavyzdžiui, skirtingus rodinius (žiniatinklio, mobiliųjų įrenginių, darbalaukio) galima sukurti pakartotinai naudojant tą patį modelį ir didelę dalį valdiklyje esančios logikos.
Mikro paslaugų architektūra
Mikropaslaugų architektūroje sudėtinga programa yra suskirstyta į mažas, nepriklausomas ir atskirai diegiamas paslaugas . Kiekviena mikropaslauga yra atsakinga už konkrečią verslo funkciją ir naudoja API (HTTP/REST, įvykiais pagrįstą pranešimų siuntimą ir kt.), kad galėtų bendrauti su kitomis.
Šis požiūris pirmenybę teikia autonominėms komandoms, kurios, jei pageidauja, gali kurti, diegti ir plėsti kiekvieną paslaugą naudodamos skirtingas technologijas. Tačiau jis sudėtingina ryšių valdymą, stebimumą ir duomenų nuoseklumą, todėl tai nėra stebuklingas sprendimas kiekvienam mažam projektui.
Monolitinė architektūra
Monolitiniame metode visa programa (sąsaja, verslo logika, prieiga prie duomenų) yra supakuojama ir diegiama kaip vienas vienetas . Tai tradicinis modelis, lengvai suprantamas ir greitai įdiegiamas mažuose ar ankstyvosios stadijos projektuose.
Laikui bėgant, jei sistema gerokai išauga, monolitinę architektūrą gali tapti sunku prižiūrėti, nes bet koks pakeitimas reikalauja diegti visą sistemą , o vienas gedimas gali paveikti visą sistemą. Todėl ji paprastai skiriama projektams, turintiems ribotus poreikius, arba kaip pirmas žingsnis prieš pertvarkant architektūrą į modulinę.
Dažniausiai pasitaikantys programinės įrangos projektavimo šablonai
Be architektūrinio lygmens, programinės įrangos projektavimas remiasi daugkartinio naudojimo projektavimo šablonais , kurie suteikia patikrintus sprendimus pasikartojančioms problemoms konstruojant klases ir objektus. Jų tikslas – pagerinti kodo lankstumą, išplėtimą ir aiškumą.
Kūrybos modeliai
Kūrimo modeliai sutelkia dėmesį į tai , kaip kuriami objektai , įkapsuliuojant egzemplioriaus kūrimo logiką, kad ji būtų atskirta nuo likusios sistemos dalies. Klasikiniai pavyzdžiai yra „Singleton“ (kuris garantuoja vieną globalų egzempliorių) ir „Factory Method“ (kuris apibrėžia sąsają objektų kūrimui, palikdamas poklasiams nuspręsti, kurią konkrečią klasę sukurti).
Struktūriniai patronai
Struktūriniai modeliai yra susiję su tuo, kaip klasės ir objektai yra komponuojami , kad susidarytų didesnės struktūros, užtikrinant, kad objektai būtų sujungti darniai. Pavyzdžiui, adapteris leidžia klasėms su nesuderinamomis sąsajomis bendradarbiauti; dekoratorius dinamiškai prideda objektui atsakomybes nemodifikuodamas jo pradinio kodo.
Elgesio modeliai
Elgesio modeliai yra skirti objektų tarpusavio komunikacijai ir atsakomybių priskyrimui . Stebėtojas apibrėžia priklausomybes taip, kad objektui pasikeitus, jo stebėtojai būtų automatiškai atnaujinami; strategija apima keičiamus algoritmus, kad klientas galėtų keisti elgesį nekeisdamas savo kodo.
Paprastas tvirtos programinės įrangos dizainas: pagrindiniai principai
Patikima sistema neatsiranda atsitiktinai: ji paprastai pagrįsta paprastu, nuosekliu ir gerai struktūrizuotu dizainu . Norint tai pasiekti, yra keletas principų ir taisyklių, kurios padeda išlaikyti kodą švarų, lengvai suprantamą ir atsparesnį klaidoms.
KISS taisyklė: viskas turi būti labai paprasta
KISS principas primena, kad dažniausiai programos veikia geriausiai, kai yra paprastos ir be nereikalingų priedų. Mažiau yra daugiau: jei galite išspręsti problemą aiškiu ir paprastu sprendimu, nesunkinkite projekto sluoksniais ir apibendrinimais, kurių niekas neprašė.
Norint pasiekti tokį paprastumą, reikia įgūdžių: esame įpratę spręsti sudėtingas problemas dar labiau jas komplikuodami, užuot skaidę į mažas, lengvai valdomas dalis . Kodui taikoma „skaldyk ir valdyk“ strategija leidžia mums izoliuoti dalines problemas ir rasti švaresnius sprendimus.
SAUSA taisyklė: nekartokite savęs
DRY siekia užtikrinti, kad kiekvienas žinių elementas sistemoje turėtų tik vieną reprezentaciją . Kai ta pati verslo logika kopijuojama keliose vietose, kiekvienas pakeitimas tampa spąstais: anksčiau ar vėliau jis modifikuojamas vienoje vietoje ir pamirštamas kitoje, todėl atsiranda neatitikimų, kuriuos sunku atsekti.
DRY taikymas apima kodo blokų, kurie iš esmės atlieka tą patį veiksmą, identifikavimą ir jų išskyrimą į pakartotinai naudojamus metodus ar komponentus . Šis metodas papildo „vieno tiesos taško“ idėją, kuri ypač aktuali verslo taisyklėse ir bendrinamuose duomenų modeliuose.
YAGNI taisyklė: tau to nereikės
YAGNI perspėja nepasiduoti pagundai numatyti funkcijas, kurių dar niekas neprašė . Labai įprasta sistemas pernelyg projektuoti, pateikiant kažką panašaus į raketą, kai klientui tereikėjo dviračio, todėl susidaro visiškai nereikalingos kūrimo, mokymo ir priežiūros išlaidos.
Geriausias būdas su tuo kovoti – sutelkti dėmesį į realius projekto reikalavimus šiuo metu , pasikliauti tokiomis praktikomis kaip testavimas (TDD), siekiant apibrėžti tik tai, ko reikia, ir pašalinti neveikiantį arba nekomentuotą kodą, kuris nenaudojamas. Jei ateityje reikės kažko daugiau, tai visada galima sukurti ant švaraus pagrindo.
Demetros dėsnis: Mažiausių žinių principas
Demetros dėsnis pataria, kad objektas turėtų sąveikauti tik su tiesioginiais bendradarbiais , o ne su „išplėstine objektų šeima“, kurią jis galėtų pasiekti sujungdamas iškvietimus (tipiškas object.getA().getB().getC()). Šios pranešimų grandinės apsunkina priežiūrą ir padaro sistemą pažeidžiamą vidiniams pokyčiams.
Sprendimas apima delegatų slėpimą ir aiškesnių prieigos metodų atskleidimą tarpinėse klasėse, taip sumažinant detalių kiekį, kurį kiekvienas objektas turi žinoti apie kitus. Tokiu būdu, jei pasikeičia bendradarbių vidinė struktūra, poveikis likusiam kodui yra kuo mažesnis.
Rūpesčių atskyrimas
Atskirų sričių atskyrimas siūlo, kad kiekvienas modulis, klasė ar komponentas turėtų būti sutelktas į aiškiai apibrėžtą atsakomybės rinkinį . Architektūriniu lygmeniu tai reiškia funkcinių sričių atskyrimą, naudojant MVC modelį (diferencijuojantį modelį, rodinį ir valdiklį) arba tokias architektūras kaip šešiakampės ar mikropaslaugos.
Kodo lygmeniu ši filosofija atsispindi tokiuose metoduose kaip metodų skirstymas į „ką“ kažkas daro ir „kaip“ tai daroma , metodų perkėlimas į klasę, kuriai iš tikrųjų priklauso jų logika (didinant sanglaudą), arba priklausomybių įkapsuliavimas naudojant priklausomybių injekciją, siekiant sumažinti susiejimą.
Aspektinis programavimas šią idėją žengia dar toliau, apimdamas įvairias sritis (registravimą, saugumą, auditą ir kt.), leisdamas pridėti įprastų veiksmų, neužteršiant verslo kodo pasikartojančiomis detalėmis.
Didelė kohezijos ir maža jungtis
Kokybiškas projektas siekia modulių, pasižyminčių didele sanglauda (jų elementai yra glaudžiai susiję) ir maža sąsaja (nedaug standžių priklausomybių tarp modulių). Kai sąsaja maža, o sąsaja didelė, kiekvienas pakeitimas tampa rizikingas ir tampa sunkiau suprasti kiekvienos sistemos dalies funkciją.
Siekiant tobulėti šioje srityje, dažnai taikomos pertvarkymo technikos, tokios kaip „Move Method“, „Encapsulate Field“ arba „Extract Class“ . Šios technikos perskirsto atsakomybę ten, kur ji prasmingiausia, ir užtikrina aiškiai apibrėžtų sąsajų naudojimą komponentų sąveikai. Tai, kartu su SOLID principais, paprastai žymi lūžio tašką kodo priežiūros srityje.
Įrankiai ir metodai programinės įrangos kūrimui šiandien
Programinės įrangos kūrimas remiasi specializuotų įrankių ekosistema , kuri palengvina viską nuo koncepcijos etapo iki programavimo. Tinkamo įrankio pasirinkimas leidžia vizualiau, bendradarbiaujant ir sparčiau atlikti darbo eigą.
Vartotojo sąsajos srityje tokie sprendimai kaip „Figma“ ar „Adobe XD“ leidžia kurti interaktyvius prototipus ir ekrano maketus, kurie padeda patikrinti navigacijos srautus, elementų išdėstymą ir vartotojo patirtį prieš pereinant prie kodo kūrimo.
Norint modeliuoti procesus, architektūras ar duomenų bazes, tokios priemonės kaip „Lucidchart“ padeda kurti srautų schemas, UML diagramas, sistemos žemėlapius ir bet kokį kitą vaizdinį vaizdavimą, reikalingą visumai suprasti. Šios diagramos tampa savotiška gyva dokumentacija, kuria vadovaujamasi priimant techninius sprendimus.
Kalbant apie diegimą, redaktoriai ir aplinkos, tokios kaip „Visual Studio Code“, įgijo didelį populiarumą dėl savo palaikymo kelioms kalboms, statinės analizės plėtinių, integracijos su versijų valdymo sistemomis ir pažangių derinimo galimybių. Visa tai padeda išlaikyti produkto kokybę viso kūrimo proceso metu.
Projektavimas ir kūrimas be kodo
Pastaraisiais metais „No-Code“ ir „Low-Code“ platformos tapo galingais įrankiais , leidžiančiais vartotojams kurti žiniatinklio ar mobiliąsias programas nerašant didelių kiekių tradicinio kodo. Daugeliu atvejų norint gauti funkcionalius sprendimus, pakanka tiesiog sujungti vizualinius komponentus, apibrėžti srautus ir konfigūruoti integracijas.
Šis metodas ypač naudingas kuriant greitą prototipų kūrimą, vidinius įrankius arba verslo programas su aiškiais ir tiksliai apibrėžtais reikalavimais. Galimybė greitai iteruoti ir atlikti pakeitimus akimirksniu leidžia lengvai pritaikyti produktą prie to, ko iš tikrųjų reikia vartotojams.
Nors šios platformos dažnai siejamos su žmonėmis, neturinčiais techninės patirties, profesionalios plėtros komandos jas taip pat naudoja projektams paspartinti, idėjoms patvirtinti arba sistemoms sujungti, nereikia visko kurti nuo nulio. Paprastos mobiliosios programėlės, mažos ERP sistemos, produktyvumo ataskaitų suvestinės ir paslaugų integracijos yra dažni pavyzdžiai.
Tačiau vien dėl to, kad platforma yra „No Code“, nereiškia, kad dizainas nustoja svarbus: vis tiek svarbu atidžiai apsvarstyti loginę architektūrą, vartotojų srautus, duomenų struktūrą ir verslo taisykles, kad būtų išvengta trapių programų, kurių neįmanoma prižiūrėti joms augant.
Visos šios sąvokos – gyvavimo ciklas, kūrimo modeliai, architektūra, projektavimo šablonai, paprastumo principai ir šiuolaikiniai įrankiai, įskaitant „No-Code“ – siekia to paties tikslo: kurti programinę įrangą, kuri efektyviai, stabiliai ir tvariai spręstų realias problemas laikui bėgant tiek tiems, kurie ją naudoja, tiek tiems, kurie ją turi prižiūrėti ir tobulinti.
