- Tarkvara disain hõlmab kõike alates nõuete määratlemisest kuni arhitektuuri, andmemudeli ja liideseni ning on võtmetähtsusega töökindlate ja hooldatavate süsteemide loomisel.
- Traditsiooniline juga elutsükkel hõlmab analüüsi, disaini, programmeerimist, testimist, juurutamist ja hooldust, kuigi tänapäeval eksisteerib see koos evolutsiooniliste, spiraalsete ja agiilsete metoodikatega.
- Hea arhitektuuri (kihid, kuusnurkne, mikroteenused, MVC jne) valimine ja disainimustrite rakendamine koos selliste põhimõtetega nagu KISS, DRY, YAGNI ja murede eraldamine parandab tarkvara kvaliteeti ja arengut.
- Kaasaegsed tööriistad ja koodivabad lähenemisviisid võimaldavad kiiremat disaini ja arendust, kuid nõuavad siiski struktuuri, voogude ja ärireeglite hoolikat planeerimist.
Tarkvara disain on palju enamat kui lihtsalt mõne koodirea kirjutamine: see on kunst muuta äriideed usaldusväärseteks, hooldatavateks ja kasutajasõbralikeks süsteemideks. Iga kellavärgiga töötava rakenduse taga on palju eelnevat tööd, mis hõlmab analüüsi, arhitektuuri, detailset disaini ja parimate tavade kogumit, mis teevadki vahet, kas tegemist on vastupidava tootega või ainult parandusi täis tootega.
Kui olete kunagi mõelnud, miks mõned rakendused on intuitiivsed ja stabiilsed, samas kui teised jooksevad kokku kohe, kui need tavapärasest kasutusest välja lülitate, siis vastus peitub peaaegu alati selles, kuidas need on loodud. Alates nõuete määratlemisest kuni arhitektuuri valimiseni, sealhulgas disainimustrid, lihtsuse põhimõtted ja arendusmetoodikad, kõik lisab (või kahjustab) lõpptulemuse kvaliteeti.
Mida tarkvara disaini all tegelikult mõeldakse?
Tarkvara disaini all peame silmas süsteemi sisemise struktuuri planeerimise protsessi , määratledes, kuidas andmed on korraldatud, millised on nende komponendid, kuidas need omavahel suhtlevad ning kuidas funktsionaalseid ja mittefunktsionaalseid nõudeid täidetakse. Praktikas on see detailne tehniline plaan, mis juhib järgnevat programmeerimist.
See disain ei piirdu ainult tehniliste aspektidega: see hõlmab ka seda, kuidas kasutaja süsteemiga suhtleb , kuidas teavet liideses esitatakse, millised navigeerimisvood on saadaval ja millist kogemust on kavandatud. Seega puudutab tarkvaradisain arhitektuuri, andmemudeleid, algoritme, kasutajaliidest (UI) ja kasutajakogemust (UX).
Ettevõtete jaoks on disain võtmetähtsusega, sest see võimaldab neil luua konkreetsetele vajadustele vastavat kohandatud tarkvara , mis on eriti oluline digitaalses maailmas, kus geneerilised tooted sageli puudujääke ei suuda. Selle etapi vahelejätmine või lihtsustamine toob tavaliselt kaasa kulude ületamisi, viivitusi ja funktsioone, mis ei vasta ootustele.
Praktikas hõlmab see kõrgetasemeliste ideede muutmist selgeteks ja teostatavateks tehnilisteks juhisteks arendusmeeskondadele. Mida parem on disain, seda lihtsam on rakendust programmeerida, testida, hooldada ja arendada.
Esialgne etapp: projekti kontekstualiseerimine enne kujundamist
Enne klassikalisse arendustsüklisse täielikku sisenemist on oluline pühendada aega probleemi ja eesmärkide määratlemise esialgsele etapile . Selles etapis pole süsteem veel üksikasjalikult kavandatud, kuid on selgeks tehtud, mida ja miks saavutada soovitakse.
Selles etapis dokumenteeritakse esialgsed tarkvaraspetsifikatsioonid , eristades funktsionaalseid nõudeid (mida süsteem peab tegema) ja mittefunktsionaalseid nõudeid (jõudlus, turvalisus, kasutatavus, tehnoloogilised piirangud jne, mis ei ole valikulised, vaid on prioritiseeritud erinevalt).
Levinud tööriist on MoSCoW klassifikatsioon, mis märgistab iga funktsiooni kas kohustuslikuks, vajalikuks, vajalikuks (võiks olla) või mittevajalikuks . See aitab ootusi kliendiga ühtlustada, ulatust läbi rääkida ja vältida tüüpilist lõputut nimekirja „kohustuslikest“ asjadest, mis hiljem projekti takistavad.
Paralleelselt seatakse tarkvara konteksti: millist probleemi see lahendab, millist kasu see toob , kes on peamised kasutajad, milliste teiste süsteemidega see integreerub ja millised keskkonna- või äripiirangud projekti mõjutavad (määrused, tähtajad, eelarve, olemasolev infrastruktuur jne).
Tarkvara elutsükli faasid juga mudelis
Üks klassikalisi arendusmudeleid on juga mudel , mis esitab elutsükli faase lineaarses järjestuses. Kuigi tänapäeval kasutatakse iteratiivsemaid lähenemisviise, on see struktuur endiselt väga kasulik kogu tarkvara loomise protsessi mõistmiseks.
1. Nõuete analüüs
Analüüsietapp seisneb rakendusele esitatavate nõuete põhjalikus kogumises, selgitamises ja dokumenteerimises . See etapp määratleb rakendusvaldkonna (konteksti, milles tarkvara töötab), süsteemi eesmärgi, ulatuse ja interaktsioonid keskkonnaga.
Süsteemi täidetavad funktsioonid on üksikasjalikult kirjeldatud , samuti kasutajate tüübid, tehnilised või juriidilised piirangud, sõltuvused teistest süsteemidest, jõudlusnõuded (reageerimisajad, samaaegsete kasutajate maht, andmemaht) ja peamised ärireeglid.
Samuti on paika pandud kasutajaliidese spetsifikatsioonid , vähemalt käitumuslikul tasandil: millised ekraanid või vaated on saadaval, milliseid põhilisi kasutajavooge järgitakse ning kuidas andmeid sisestatakse ja kuvatakse. Püsivuse tasandil on määratletud andmebaasi nõuded ja välised integratsioonid.
Selles etapis tehtud viga võib hilisemates etappides kaasa tuua väga kulukaid ümbertöid nii aja kui ka raha osas. Seetõttu on ülioluline olla detailide suhtes täpne, pidevalt kliendiga ühendust pidada ning tagada, et kõik oleks ideaalselt dokumenteeritud ja kokku lepitud.
2. Projekteerimine: nõuetest tehnilise jooniseni
Kui nõuded on paika pandud, algab disainifaas, kus määratletakse süsteemi üldine arhitektuur ja sisemine struktuur . See hõlmab otsustamist, millised komponendid kaasatakse, kuidas need korraldatakse, kuidas nad omavahel suhtlevad ja milliseid tehnoloogiaid kasutatakse.
Disain hõlmab nõuete täitmiseks vajalikke andmestruktuure, algoritme ja käitumist , võttes arvesse analüüsis tuvastatud piiranguid. Samuti loob see aluse rakendamiseks, luues arendajatele selge dokumentatsiooni koos operatiivsete juhistega.
See etapp hõlmab süsteemi arhitektuuri määratlemist: millised tarkvaramoodulid eksisteerivad, milliseid liideseid need pakuvad , millised on nendevahelised seosed ja milliseid kohustusi igaüks võtab. Sealt edasi valitakse disainimustrid, arhitektuuristiilid ja konkreetsed tehnoloogiad (raamistikud, andmebaasid, käituskeskkonnad jne).
Kujunduse esitamiseks ja põhjendamiseks saab kasutada formaalseid keeli ja diagramme , näiteks UML-i klassiskeeme, tegevusskeeme, Gantti tüüpi vooskeeme, piirangukeeli nagu OCL või isegi spetsialiseeritumaid mudeleid (näiteks Petri võrke), kui on vaja modelleerida samaaegsust või keerulisi vooge.
Oluline on mõista, et erinevalt nõuete analüüsist sõltub disain tõepoolest valitud tehnoloogiatest . Näiteks kuusnurkse arhitektuuri, mikroteenuste või monoliitse lähenemisviisi kasutamise otsus mõjutab otseselt koodi ülesehitust ja vastutuse jaotust.
3. Programmeerimine või rakendamine
Kui plaanid on valmis, on aeg kirjutada kood. Programmeerimine hõlmab disaini tõlkimist funktsionaalseks rakenduseks , austades arhitektuurilisi otsuseid, kokkulepitud mustreid ja meeskonna stiilikonventsioone.
Selles etapis kasutatakse tavaliselt integreeritud arenduskeskkondi (IDE-sid), näiteks Visual Studio Code'i, IntelliJ-d või sarnaseid , mis ühendavad endas redaktori, kompilaatori, ehitustööriistad ja siluri. Need keskkonnad hõlbustavad süntaksivigade, duplikaatkoodi või kasutamata muutujate varajast tuvastamist, parandades tootlikkust ja kvaliteeti.
Programmeerimise ajal on hea tava teha esialgne põhiline silumine , parandada ilmseid vigu ja veenduda, et koodiüksused (meetodid, klassid, moodulid) toimivad täpselt nii, nagu peaks. Tehniliste otsuste ja iga osa funktsionaalsuse nõuetekohane dokumenteerimine on ülioluline, et teised arendajad saaksid tööd hiljem jätkata.
Ükskõik kui laitmatud analüüsi- ja disainifaasid ka poleks olnud, võib halvasti teostatud kood või loogikavigadega kood kogu projekti rikkuda. Seetõttu on vaja programmeerimisega kaasneda heade kvaliteeditavade, automatiseeritud testimise ja vastastikuse koodi ülevaatamise abil.
4. Testimine ja kontrollimine
Kui kood on rakendatud, on aeg kontrollida, kas süsteem käitub ootuspäraselt. Testimisetapp keskendub tarkvara vastavuse valideerimisele alguses määratletud nõuetele: mitte ainult sellele, et see "ei kukuks kokku", vaid et see teeb täpselt seda, mida lubas.
See etapp tuvastab peamiselt loogilisi või kontseptuaalseid vigu , mis on tüüpilistest kompileerimisvigadest peenemad. Kavandatakse ja teostatakse ühik-, integratsiooni-, süsteemi- ja jõudlustestid ning vajaduse korral viiakse kliendi või lõppkasutajatega läbi vastuvõtutestid.
Igasugune ootamatu käitumine või lahknevus spetsifikatsioonidega teatatakse arendajatele, kes peavad leidma ja kõrvaldama selle põhjuse. Seda testimise, tuvastamise, parandamise ja uuesti testimise tsüklit korratakse seni, kuni saavutatakse tarkvara tootmisse viimiseks vastuvõetav kvaliteeditase.
5. Juurutamine või tootmise käivitamine
Kui süsteem on läbinud vajalikud testid, installitakse tarkvara ja see alustab oma tegelikku tööiga . Juurutamine võib rakenduse tüübist olenevalt tähendada erinevaid asju.
Kui tegemist on kommertstootega, mida müüakse või levitatakse vabalt, langeb juurutamine tavaliselt kokku ametliku turuletoomisega . Ettevõtte jaoks loodud kohandatud arenduse puhul tähendab see paigaldamist kliendi keskkondadesse ja lõplikku testimist reaalsetes tingimustes.
6. Säilitamine ja areng
Kui tarkvara on tootmises, siseneb see pidevasse elutsükli faasi, kus on oluline parandada probleeme, uuendada ja arendada funktsioone , et see pakuks aja jooksul jätkuvalt väärtust.
Hooldus liigitatakse tavaliselt kahte põhikategooriasse: korrigeeriv ehk rutiinne hooldus , mis tegeleb vigade parandamisega, mida testimise ajal ei avastatud või mis ilmnevad süsteemi kasutamisel ettenägematutes olukordades; ja evolutsiooniline hooldus , mis tutvustab uusi võimalusi või kohandab tarkvara äritegevuse muutustega.
Iga seda tüüpi sekkumine võib nõuda uusi analüüsi, disaini, arenduse ja testimise minifaase . Liiga jäikade mudelite puhul on tsüklisse tagasipöördumine keeruline ja kulukas, põhjustades projektide viivitusi ja kõrvalekaldeid kokkulepitud tähtaegadest.
Muud arendusmudelid: evolutsiooniline, spiraalne ja agiilne
Jugamudel pole ainus viis protsessi korraldamiseks. On olemas lähenemisviise, mis seavad esikohale iteratsiooni, pideva kohandamise ja koostöö kliendiga, et vähendada riske ja lühendada tagasiside tsükleid.
Evolutsiooniline mudel ja prototüüpimine
Evolutsioonimudel tutvustab prototüübi kontseptsiooni kui süsteemi lihtsustatud versiooni, mis tarnitakse kliendile varakult, et saada kiiret tagasisidet. See ei pea olema täielikult funktsionaalne; see peab lihtsalt võimaldama liidese või teatud põhifunktsioonide visualiseerimist.
Tüüpiline tsükkel hõlmab prototüübi loomist, selle üleandmist, tagasiside kogumist ja vajalike muudatuste sisseviimist. Seda korratakse seni, kuni saavutatakse piisav küpsusaste lõpliku rakenduse teostamiseks.
Prototüüp võib olla sama lihtne kui ekraanide staatiline makett, kuid see on siiski kasulik funktsionaalsete ja disaininõuete valideerimiseks enne ühegi tootmiskoodi rea kirjutamist. See ei paranda otseselt programmeerimise kvaliteeti, mis sõltub jätkuvalt meeskonna parimatest tavadest.
Spiraalne mudel
Spiraalmudel esitab arendust korduva faaside tsüklina (planeerimine, analüüs, disain, rakendamine, testimine), mis viiakse läbi mitmes voorus, millest igaüks on eelmisest kõrgema detailsuse ja funktsionaalsusega.
Selle kõige iseloomulikum omadus on iga iteratsiooni selgesõnaline riskihindamine . Enne edasiliikumist tuvastatakse ja analüüsitakse tehnilisi, ärilisi ja planeerimisriske ning tehakse leevendusotsuseid. Sel põhjusel peetakse seda mõnikord "metamudeliks", millesse saab lisada ka teisi lähenemisviise.
Agile'i metoodikad
Agile'i filosoofia on enamat kui lihtsalt konkreetne mudel, see on põhimõtete ja tavade kogum, mille eesmärk on järkjärguline väärtuse loomine , muutustega kohanemine ja kliendiga pideva koostöö säilitamine.
Agiilses kontekstis arendatakse tarkvara lühikeste iteratsioonide (sprintide) kaupa , mille käigus disainitakse, arendatakse, testitakse ja tarnitakse toote väike funktsionaalne osa. Klient näeb varajasi tulemusi, saab tööd vastavalt oma tegelikele vajadustele tähtsuse järjekorda seada ja ümber suunata ning arendusmeeskonnal on suurem autonoomia.
Kuigi disain jääb võtmetähtsusega, on trendiks evolutsiooniline disainilähenemisviis : defineeritakse esialgne arhitektuur, mis on alustamiseks piisavalt kindel, ning seda täiustatakse ja laiendatakse uute nõuete ilmnemisel või kasutushüpoteeside valideerimisel.
Tarkvaraarhitektuur: süsteemi skelett
Tarkvaraarhitektuuri võib mõista kui süsteemi kõrgetasemelist struktuuri : selle peamised ehitusplokid, nende avalikud liidesed ja nendevahelised seosed. Järgides selliseid definitsioone nagu Software Engineering Institute, kirjeldab arhitektuur süsteemi struktuure, neid moodustavaid elemente, nende nähtavaid omadusi ja nendevahelisi seoseid.
Sellel arhitektuurilisel visioonil on mitu eesmärki. Ühelt poolt võimaldab see arendajatel mõista, kuidas iga osa tervikusse (moodulid, liidesed, suhtlusmehhanismid, sõltuvused) sobitub. Teisest küljest toimib see ühise viitena tehniliste ja disainiotsuste koordineerimiseks kogu tarkvaraarenduse elutsükli vältel.
Lisaks suunab hea arhitektuur süsteemi soovitud kvaliteediomaduste poole: turvalisus, skaleeritavus, jõudlus , hooldatavus, juurutamise lihtsus jne. Arhitektuuriliste otsuste tegemine ilma neid tegureid arvestamata toob sageli kaasa süsteeme, mida on raske arendada ja mis on muutuste ees habras.
Tarkvaraarhitektuuri ja disaini erinevus
Kuigi neid termineid kasutatakse mõnikord sünonüümidena, toimivad tarkvaraarhitektuur ja disain erinevatel tasanditel. Arhitektuur toimib abstraktsemal tasandil , määratledes süsteemi üldise struktuuri, selle peamised komponendid, nende vastutusalad ja omavahelised seosed.
Tarkvara disain seevastu süveneb iga komponendi rakendamiseks vajalikesse tehnilistesse üksikasjadesse : spetsiifilised algoritmid, sisemised andmestruktuurid, klasside korraldus, moodulite vahelised täpsed liidesed, veakäsitlus jne.
Hea analoogia on hoone ehitamine: arhitektuur määrab põrandate, sammaste, konstruktsioonimaterjalide paigutuse ja ruumide üldise kasutuse; detailplaneering käsitleb paigaldisi, viimistlust, mööblit ja iga ruumi spetsiifilisi detaile. Mõlemad on lõpptulemuse saavutamiseks olulised, kuid toimivad erinevas mastaabis ja ajahetkel.
Tarkvaraarhitektuuri peamised tüübid
Sõltuvalt projekti tüübist, meeskonna suurusest ja ärivajadustest saab kasutada erinevaid arhitektuuristiile . Igal neist on oma eelised ja puudused, mida tuleks mõista, et vältida sobimatute lahenduste pealesurumist.
"Spagettide" arhitektuur
Süsteeme, kus esitlus-, äri- ja andmeloogika on omavahel segatud ilma selge eraldamiseta, nimetatakse kõnekeeles "spagettide" arhitektuuriks . Seda tüüpi arhitektuuri leidub sageli vanemates rakendustes või projektides, mis on kasvanud ilma tõsise arhitektuurilise planeerimiseta.
Tulemuseks on sassis koodipuder, mis on täis ristsõltuvusi, kus isegi väikesed muudatused hõlmavad arvukate valdkondade muutmist , muutes hoolduse õudusunenäoks. See on ideaalne näide sellest, mida tänapäevased kihilised või domeenipõhised arhitektuurid püüavad vältida.
Kihiline arhitektuur
Kihiline arhitektuur tekkis just selle kaose vastu võitlemiseks. See jagab süsteemi täpselt määratletud kihtideks , millest igaüks vastutab kindla ülesande tüübi eest: esitlus (kasutajaliides), äriloogika, andmetele juurdepääs jne.
Vastutuse segmenteerimise abil on ühe kihi muudatustel teistele väiksem mõju . Näiteks saate muuta teabe esitusviisi ilma äriloogikat mõjutamata või muuta andmebaasimootorit, jättes samal ajal ärikihi puutumata.
Kuusnurkne arhitektuur
Kuusnurkne arhitektuur (tuntud ka kui pordid ja adapterid) püüab äriloogikat täielikult ülejäänud infrastruktuurist isoleerida . Domeeni tuum pakub porte (liideseid) ja selle ümber on ühendatud adapterid andmebaaside, väliste API-de, kasutajaliideste jms jaoks.
See lähenemisviis võimaldab teha muudatusi välistes tehnoloogiates (makseteenuse pakkuja, sõnumsidesüsteem, veebiliides) ilma rakenduse tuuma täielikku ümberkirjutamist nõudmata . Adaptereid saab asendada või muuta ilma valdkonda mõjutamata, suurendades nii süsteemi testitavust kui ka pikaealisust.
MVC (mudeli-vaate-kontrolleri) arhitektuur
MVC arhitektuurimuster jagab rakenduse kolmeks komponendiks: mudel, vaade ja kontroller . Mudel haldab andmeid ja ärireegleid, vaade tegeleb esitlusega ning kontroller toimib vahendajana, võttes vastu kasutajate päringuid, korraldades toiminguid ja otsustades, millist vaadet kuvada.
See eraldamine võimaldab kasutajaliidesel areneda äriloogikast sõltumatult . Näiteks saab luua erinevaid vaateid (veebi-, mobiili-, töölauavaateid), taaskasutades samal ajal sama mudelit ja suurt osa kontrolleri loogikast.
Mikroteenuste arhitektuur
Mikroteenuste arhitektuuris on keeruline rakendus jagatud väikesteks, sõltumatuteks ja eraldi juurutatavateks teenusteks . Iga mikroteenus vastutab kindla ärifunktsiooni eest ja pakub API-sid (HTTP/REST, sündmustepõhine sõnumside jne) teistega suhtlemiseks.
See lähenemisviis soosib autonoomseid meeskondi, kes saavad soovi korral iga teenust arendada, juurutada ja skaleerida, kasutades erinevaid tehnoloogiaid. See aga toob kaasa keerukust kommunikatsioonihalduses, jälgitavuses ja andmete järjepidevuses, seega pole see iga väikese projekti jaoks imerohi.
Monoliitne arhitektuur
Monoliitse lähenemisviisi puhul pakendatakse ja juurutatakse kogu rakendus (liides, äriloogika, andmetele juurdepääs) ühtse üksusena . See on traditsiooniline mudel, mida on lihtne mõista ja kiire rakendada väikestes või algstaadiumis projektides.
Aja jooksul, kui süsteem oluliselt kasvab, võib monoliitset arhitektuuri olla raske hooldada, kuna iga muudatus nõuab kogu süsteemi juurutamist ja üks tõrge võib mõjutada kogu süsteemi. Seetõttu on see tavaliselt reserveeritud piiratud vajadustega projektidele või esimese sammuna enne moodularhitektuuride suunas ümberkujundamist.
Kõige levinumad tarkvaradisaini mustrid
Lisaks arhitektuurilisele tasemele tugineb tarkvara disain korduvkasutatavatele disainimustritele , mis pakuvad tõestatud lahendusi klasside ja objektide konstrueerimisel korduvatele probleemidele. Nende eesmärk on parandada koodi paindlikkust, laiendatavust ja selgust.
Loomingulised mustrid
Loomingulised mustrid keskenduvad sellele , kuidas objekte luuakse , kapseldades eksemplari loomise loogika, et see ülejäänud süsteemist lahti siduda. Klassikaliste näidete hulka kuuluvad Singleton (mis garanteerib ühe globaalse eksemplari) ja Factory Method (mis määratleb objektide loomise liidese, jättes alamklasside otsustada, millist konkreetset klassi eksemplari luua).
Strukturaalsed patronid
Struktuurimustrid käsitlevad seda , kuidas klassid ja objektid on kokku pandud suuremate struktuuride moodustamiseks, tagades üksuste sidusa kombineerimise. Näiteks adapter võimaldab ühildumatute liidestega klassidel koostööd teha; dekoraator lisab objektile dünaamiliselt vastutuse ilma selle algset koodi muutmata.
Käitumismustrid
Käitumismustrid on suunatud objektide vahelisele suhtlusele ja vastutuse määramisele . Vaatleja määratleb sõltuvused nii, et objekti muutumisel uuendatakse automaatselt ka selle vaatlejaid; strateegia hõlmab vahetatavaid algoritme, nii et klient saab käitumist muuta ilma oma koodi muutmata.
Lihtne disain vastupidava tarkvara jaoks: peamised põhimõtted
Tugev süsteem ei teki juhuslikult: see põhineb tavaliselt lihtsal , sidusal ja hästi struktureeritud disainil . Selle saavutamiseks on olemas rida põhimõtteid ja reegleid, mis aitavad hoida koodi puhta, kergesti mõistetava ja veakindlamana.
KISS-reegel: hoia see ülilihtsana
KISS-printsiip tuletab meile meelde, et enamasti toimivad rakendused kõige paremini siis, kui need on lihtsad ja vabad ebavajalikest lisadest. Vähem on rohkem: kui suudad probleemi lahendada selge ja arusaadava lahendusega, siis ära tee disaini keeruliseks kihtide ja üldistustega, mida keegi pole palunud.
Sellise lihtsuse saavutamine nõuab oskusi: oleme harjunud keerulisi probleeme lahendama veelgi keerulisemaks muutes, selle asemel, et neid väikesteks ja hallatavateks osadeks jagada . Koodi puhul rakendatav „jaga ja valitse” strateegia võimaldab meil isoleerida alamprobleeme ja leida puhtamaid lahendusi.
KUIV Reegel: Ära korda ennast
DRY eesmärk on tagada, et igal teadmusüksusel oleks süsteemis ainult üks esitus . Kui sama äriloogikat kopeeritakse mitmesse kohta, muutub iga muudatus lõksuks: varem või hiljem muudetakse seda ühes kohas ja unustatakse teises, tekitades raskesti jälgitavaid vastuolusid.
DRY rakendamine hõlmab sama asja tegevate koodiplokkide tuvastamist ja nende eraldamist korduvkasutatavateks meetoditeks või komponentideks . See lähenemisviis täiendab "ühtse tõepunkti" ideed, mis on eriti oluline ärireeglite ja jagatud andmemudelite puhul.
YAGNI reegel: Sa ei vaja seda
YAGNI hoiatab meid kiusatuse eest ette näha funktsioone, mida keegi pole veel taotlenud . On väga tavaline, et süsteeme üle projekteeritakse, pakkudes midagi raketilaadset, kui klient vajas ainult jalgratast, mille tulemuseks on täiesti ebavajalikud arendus-, koolitus- ja hoolduskulud.
Parim viis selle vastu võitlemiseks on keskenduda projekti tegelikele nõuetele hetkel , tugineda sellistele tavadele nagu testimispõhine arendus (TDD), et määratleda ainult see, mida on vaja, ja kõrvaldada surnud või kommenteerimata kood, mida ei kasutata. Kui tulevikus on vaja midagi enamat, saab selle alati ehitada puhtale alusele.
Demeteri seadus: vähima teadmise printsiip
Demeteri seadus soovitab, et objekt peaks suhtlema ainult oma otseste kaastöötajatega , mitte aga objektide "laiendatud perekonnaga", kuhu see saaks aheldatud kõnede abil jõuda (tüüpiline object.getA().getB().getC()). Need sõnumiahelad muudavad hoolduse keeruliseks ja süsteemi sisemiste muudatuste suhtes haavatavaks.
Lahendus hõlmab delegaatide peitmist ja selgemate juurdepääsumeetodite paljastamist vaheklassides, vähendades seeläbi detailide hulka, mida iga objekt peab teiste kohta teadma. Sel viisil minimeeritakse kaastöötajate sisemise struktuuri muutumise mõju ülejäänud koodile.
Murede lahusus
Murede eraldamine eeldab, et iga moodul, klass või komponent peaks keskenduma täpselt määratletud vastutusaladele . Arhitektuurilisel tasandil tähendab see funktsionaalsete valdkondade eraldamist, kasutades MVC mustrit (eristav mudel, vaade ja kontroller) või selliseid arhitektuure nagu kuusnurkne või mikroteenused.
Kooditasandil kajastub see filosoofia sellistes tehnikates nagu meetodite jagamine "mida" miski teeb ja "kuidas" seda tehakse , meetodite liigutamine klassi, kuhu nende loogika tegelikult kuulub (suurendades sidusust) või sõltuvuste kapseldamine sõltuvuste süstimise abil, et vähendada sidumist.
Aspektipõhine programmeerimine viib selle idee sammu edasi, hõlmates valdkondadevahelisi huvisid (logimine, turvalisus, auditeerimine jne), võimaldades lisada tavalisi käitumisviise ilma ärikoodi korduvate detailidega saastamata.
Kõrge kohesioon ja madal sidumine
Kvaliteetne disain otsib mooduleid, millel on kõrge kohesioon (nende elemendid on omavahel tihedalt seotud) ja madal sidestus (moodulite vahel on vähe jäiku sõltuvusi). Kui kohesioon on madal ja sidestus kõrge, muutub iga muudatus riskantseks ja süsteemi iga osa funktsiooni mõistmine muutub raskemaks.
Selle valdkonna täiustamiseks kasutatakse sageli refaktoreerimistehnikaid, näiteks Move Method, Encapsulate Field või Extract Class . Need tehnikad jaotavad vastutuse ümber seal, kus see on kõige mõttekam, ja jõustavad komponentide vaheliseks interaktsiooniks täpselt määratletud liideste kasutamist. See koos SOLID-põhimõtetega tähistab tavaliselt koodi hooldatavuse pöördepunkti.
Tänapäeval tarkvara kujundamise tööriistad ja lähenemisviisid
Tarkvara disain tugineb spetsiaalsete tööriistade ökosüsteemile , mis hõlbustab kõike alates kontseptuaalsest faasist kuni programmeerimiseni. Õige tööriista valimine võimaldab visuaalsemat, koostööaltimat ja kiiremat töövoogu.
Kasutajaliidese valdkonnas võimaldavad sellised lahendused nagu Figma või Adobe XD luua interaktiivseid prototüüpe ja ekraanipilte, mis aitavad enne koodi juurde liikumist valideerida navigeerimisvooge, elementide paigutust ja kasutajakogemust.
Protsesside, arhitektuuride või andmebaaside modelleerimiseks aitavad sellised tööriistad nagu Lucidchart luua vooskeeme, UML-diagramme, süsteemikaarte ja muid visuaalseid esitusi, mis on vajalikud terviku mõistmiseks. Nendest diagrammidest saab omamoodi elav dokumentatsioon, mis juhib tehnilisi otsuseid.
Rakenduse poolelt on redaktorid ja keskkonnad, näiteks Visual Studio Code, saavutanud märkimisväärse populaarsuse tänu oma toetusele mitmele keelele, staatilise analüüsi laiendustele, integratsioonile versioonikontrollisüsteemidega ja täiustatud silumisvõimalustele. Kõik see aitab kaasa toote kvaliteedi säilitamisele kogu arendusprotsessi vältel.
Koodivaba disain ja arendus
Viimastel aastatel on No-Code ja Low-Code platvormid esile kerkinud võimsate tööriistadena , mis võimaldavad kasutajatel luua veebi- või mobiilirakendusi ilma suures koguses traditsioonilist koodi kirjutamata. Paljudel juhtudel piisab funktsionaalsete lahenduste saamiseks lihtsalt visuaalsete komponentide kombineerimisest, voogude määratlemisest ja integratsioonide konfigureerimisest.
See lähenemisviis on eriti kasulik kiire prototüüpimise, sisemiste tööriistade või selgete ja täpselt määratletud nõuetega ärirakenduste jaoks . Kiire iteratsiooni ja muudatuste tegemise võimalus lennult muudab toote kohandamise kasutajate tegelike vajadustega lihtsaks.
Kuigi neid platvorme seostatakse sageli inimestega, kellel puudub tehniline kogemus, kasutavad professionaalsed arendusmeeskonnad neid ka projektide kiirendamiseks, ideede valideerimiseks või süsteemide ühendamiseks ilma, et peaksid kõike nullist üles ehitama. Levinud näited on lihtsad mobiilirakendused, väikesed ERP-d, tootlikkuse armatuurlauad ja teenuste integratsioonid.
Kuid see, et platvorm on koodivaba, ei tähenda, et disain enam ei oma tähtsust: siiski on oluline hoolikalt kaaluda loogilist arhitektuuri, kasutajavooge, andmestruktuuri ja ärireegleid, et vältida habrasid rakendusi, mida on võimatu kasvades hooldada.
Kõik need kontseptsioonid – elutsükkel, arendusmudelid, arhitektuur, disainimustrid, lihtsuse põhimõtted ja kaasaegsed tööriistad, sealhulgas koodi puudumine – koonduvad sama eesmärgi nimel: luua tarkvara, mis lahendab reaalseid probleeme tõhusalt, stabiilselt ja aja jooksul jätkusuutlikult nii neile, kes seda kasutavad, kui ka neile, kes peavad seda hooldama ja arendama.
