Patru idei pentru imbunatatirea Software Design-ului

[SynTAX]

Software Design se num?r? printre ultimele trenduri care impresioneaz? domeniul IT. Se pare c? în fiecare an apar alte câteva idei de design. Mai întâi au fost design patterns. MVC este modul în care construim aplica?ii web, în timp ce idei cum ar fi: domain driven design, porturi ?i adaptoare, microservices se bucur? de adop?ie ?i interes crescut.

1. Fiecare decizie de design are avantaje ?i dezavantaje

Când facilitez exerci?ii de arhitectur? sau design, cum ar fi Architectural Kata,Code Retreats sau unul dintre workshop-urile de software design, le cer participan?ilor s? creeze un design, fie scriind cod fie sub form? de diagram?. Apoi discut?m ?i oferim feedback solu?iei lor. De multe ori, un participant îmi cere s? dau „cea mai bun? solu?ie” pentru problema respectiv?. R?spunsul nea?teptat este c? nu exist? „cea mai bun? solu?ie”.

Realitatea este c? orice decizie de software _design_are avantaje ?i dezavantaje. Dar la urma urmei, iat? o list? succint? a caracteristicilor unui design bun:

• Dezvoltare rapid?,
  
• U?or de schimbat,
  
• U?or de g?sit problemele,
  
• Sigur,
  
• Rapid,
  
• Scalabil,
  
• Reduce ?ansa de gre?eli.
  

Este imposibil s? scrii cod care ob?ine un 10/10 pentru toate aceste criterii simultan. De aceea avem sloganul „quick and dirty” în loc de „corect ?i rapid ?i scalabil ?i f?r? bug-uri ?i u?or de schimbat ?i ...”. Întrebarea important? devine atunci: pentru care criteriu este acceptabil s? ob?ii un 8/10, 6/10 sau 4/10, în contextul în care te afli.

Acest lucru se traduce în „cea mai potrivit?” solu?ie pentru un anumit context; probabil c? nu va ar?ta precum „cea mai bun? solu?ie” la care te gândeai. Iat? o poveste personal? pentru a sprijini acest fapt. Când dezvoltam în C#, am descoperit c? am putea folosi delegates ca expresii lambda, reducând astfel num?rul de linii de cod pe care trebuia s? le scriu. Am rezistat tenta?iei deoarece colegii mei ar fi g?sit acest cod confuz ?i ar fi crescut ?ansa de a face gre?eli. A? fi putut încerca s?-i înv?? acest mod de a scrie cod, dar nu eram atât de bun la instruirea oamenilor pe atunci. A fost o decizie con?tient? pentru binele proiectului.

Am dou? moduri de a identifica avantajele ?i dezavantajele, astfel încât s? ob?ine?i software design mai bun. Ori de câte ori evalu?m solu?ii poten?iale pentru o problem?:

List?m alternativele, avantajele ?i dezavantajele fiec?reia dintre ele ?i apoi facem o alegere con?tient? pentru una dintre solu?ii.

Experiment?m: începem punerea în aplicare a uneia dintre solu?ii, fiind gata s? arunc?m sau s? schimb?m solu?ia dac? nu este destul de bun?.

Acest proces nu trebuie s? ia mult timp. De obicei, o jum?tate de or? sunt mai mult decât suficiente pentru prima op?iune ?i maxim dou? ore pentru a doua. Dup? pu?in? practic?, vei începe s? faci aceasta în mod automat pentru cele mai multe decizii.

Dac? exist? un lucru pe care îl po?i înv??a din aceast? lege, acesta ar trebui s? fie: Pentru a face software _design_mai bun, identific? avantajele ?i dezavantajele solu?iei pe care o alegi.

Întrebarea de reflec?ie: Care sunt dezavantajele clasei la care lucrezi? Ce ar putea merge prost?

2. Programatorii sunt utilizatorii Software Design-ului

Ori de câte ori vorbim despre design în alte domenii decât software-ul, discut?m din punct de vedere orientat c?tre utilizator. Produsele Apple sunt renumite pentru c? se concentreaz? pe experien?a unui utilizator cu dispozitivul lui: cum se simte, cum arat?, cât de repede r?spunde, sunetele pe care le face, etc. .

Software design-ul este singurul tip de design care pare a nu avea utilizator. La urma urmei, utilizatorul final nu are nicio idee despre cum func?ioneaz? software-ul ?i nici nu-i pas?. Tot ce le pas? utilizatorilor finali este ca software-ul s? func?ioneze cum trebuie.

Atunci de ce ar trebui s? ne pese de structura intern? a software-ului? Exist? motive economice foarte bune pentru a face acest lucru. În cazul în care software-ul nu este u?or de schimbat, dezvoltatorii nu vor putea ad?uga caracteristici rapid, ducând la o poten?ial? pierdere a clien?ilor. Atunci când structura software-ului nu este organizat? în mod corespunz?tor, ar putea s? apar? mai multe bug-uri care necesitând mai multe ore de s?pat prin cod pentru a le repara, ar cre?te costurile de între?inere.

Acestea nu sunt probleme noi. Designurile ini?iale pentru multe obiecte pe care le folosim acum zilnic au început prin a fi slabe, dar au fost îmbun?t??ite în timp. Cum? Cheia st? în a asculta feedback-ul utilizatorilor.

În echipa noastr?, Claudia lucreaz? full-time în timp ce eu lucrez part-time la un produs eHealth. În afar? de sarcinile mele de dezvoltare, ajut ca mentor, coach ?i o ajut cu decizii mai dificile. Una dintre întreb?rile mele recurente este: „Ce a fost greu de schimbat în ultimele dou? s?pt?mâni?”. Pe baza acestei întreb?ri, am îmbun?t??it viteza de modificare a codului în zonele unde se schimb? cel mai mult.

Software design-ul are utilizator. Utilizatorul este dezvoltatorul care va trebui s? schimbe codul pe care îl scrii. Dac? folosi?i collective code ownership (ca majoritatea echipelor Scrum), ar fi bine s? lua?i în considerare user-centric software design (software design orientat c?tre utilizator).

?i iat? o idee pentru tine: ce zici despre rularea de teste de usability pe software design pentru a reduce costurile de dezvoltare?

Pentru a face software design mai bun, analizeaz?-l din punctul de vedere al altor dezvoltatori.

Întrebarea de reflec?ie: Care sunt unele dintre plângerile comune ale colegilor t?i de echip? legate de cod? Ce este dificil s? schimba?i? Cum ai putea s?-l faci mai u?or?

3. Numele conteaz? mult mai mult decât î?i imaginezi

Software-ul este cunoa?tere executabil?. De exemplu, când scrii o aplica?ie de contabilitate, se codific? tot ce ?tii despre regulile ?i procedurile de contabilitate. Cum au ajuns aceste cuno?tin?e în aplica?ie? Prin preluarea acestora de la speciali?ti ?i trecerea prin creierul dezvoltatorilor pentru a le transforma în cod.

O observa?ie aparte este c? cele dou? caracteristici care diferen?iaz? dezvoltatorii de restul lumii este c? ei în?eleg calculatoarele ?i pot gândi cu un nivel foarte ridicat de precizie. De aceea nu cred în programarea vizual? f?cut? de speciali?ti.

Cum înva?? ?i î?i structureaz? cuno?tin?ele oamenii? Prin atribuirea de nume lucrurilor. Dac? te gânde?ti la anii de ?coal?, î?i aminte?ti de înv??area despre numere, opera?ii aritmetice, tabla înmul?irii etc..Acestea sunt doar nume date unor concepte, nume care ne ajut? s? comunic?m unul cu cel?lalt despre idei complexe.

V? invit s? realiza?i urm?torul test. Scrie?i unele dintre numele claselor, metodelor ?i variabilelor din codul pe care lucra?i. Apoi nota?i-v? ceea ce face aplica?ia. Apoi num?ra?i câte dintre aceste nume corespund domeniului de aplicare. Sau întreba?i pe cineva care nu ?tie la ce lucra?i s? ghiceasc? ce face aplica?ia doar pe baza listei de nume. În cazul în care au ghicit, atunci v? rog s? m? contacta?i pentru c? vreau s? înv?? de la voi cum face?i.

Acest test arat? o deconexiune tipic? între ceea ce aplica?ia face ?i cum î?i structureaz? dezvoltatorii cuno?tin?ele în cod. De ce este acest lucru r?u? Deoarece creierul trebuie s?-?i petreac? timp valoros încercând s? traduc? ceea ce cite?te c?tre ce face aplica?ia. Acest lucru duce la reducerea productivit??ii ?i te obose?te.

Nu exist? în acest moment nici un mod definitiv pentru a elimina distan?a dintre cuno?tin?e ?i cod. Aceasta poate fi îns? redus? mult de iterarea prin continuumul numelor definit de JB Rainsberger. Un sfat: ve?i g?si c? este foarte dificil la început, dar devine mai u?or cu exerci?iu.

Pentru a face software design mai bun, nume?te clasele, metodele ?i variabilele cât mai aproape de domeniul de business posibil.

Întrebarea de reflec?ie: Ce face aplica?ia ta? Care sunt câteva nume specifice businessului? Sunt acestea prezente în cod?

4. Integritatea conceptual? este principiul pierdut pentru software design bun

Acum 40 de ani, Fred Brooks a scris o carte pentru dezvoltarea de software numit „The Mythical Man Month”. Cartea con?ine multe constat?ri esen?iale despre dezvoltarea de software ?i inginerie pe care cei mai mul?i oameni care lucreaz? în industrie nu le ?tiu ?i nu le aplic? pentru c? nu au citit cartea.

Cea mai important? idee de design din carte este urm?toarea:

Voi sus?ine c? integritatea conceptual? este cel mai important aspect în proiectarea sistemului. Este mai bine s? avem un sistem care omite anumite caracteristici anormale ?i îmbun?t??iri, dar care reflect? un set de idei de design, decât de a avea unul care con?ine multe idei bune, dar independente ?i necoordonate.

• Fred Brooks, The Mythical Man Month
  

Pagina wiki a lui Ward Cunningham pe aceast? tem? ofer? urm?toarele exemple de integritate conceptual?:

Putem identifica exemple specifice, binecunoscute de Conceptual Integrity? V? prezint o list? de asemenea exemple specifice, care nu este definitiv?:

• Unix (bazat pe no?iunea de „dosar” (de exemplu, directoare, dispozitive, sisteme de fi?iere, cu named pipes ?i sockets sunt tot felul de fi?iere);
  
• Smalltalk („totul este un obiect”, ?i micul set de alte principii care îl înso?esc);
  
• SQL („toate datele se afl? în tabele”, cu chei ?i constrângeri
  
• Lisp („totul este o list?”);
  

De ce este util? integritatea conceptual?? Probabil din cauza modului în care creierul nostru func?ioneaz?. Memoria omeneasc? de lucru se limiteaz? la p?strarea a patru articole în paralel, dar exist? o metod? de a o p?c?li: fiecare element poate fi de fapt un set de concepte înrudite (un a?a numit chunk). Când ai de luat decizii de design dificile, cu siguran?? ai nevoie s? iei în considerare mai mult de patru lucruri în acela?i timp. Ajut? dac? sunt similare, deoarece creierul poate s? le prelucreze, permi?ându-?i s? iei decizii mai informate de design.

Integritatea conceptual? poate fi aplicat? la diferite niveluri, de la variabile, metode la clase. De exemplu, s? facem urm?torul test. Nota?i numele câtorva clase ?i numele tuturor metodelor lor publice. Arat? interfa?a clasei cuiva care nu ?tie la ce lucra?i ?i întreba?i ce face clasa respectiv?. Întreba?i-i dac? e ceva ce pare c? nu e la locul ei în acea clas?. Dac? ghicesc ?i totul se potrive?te, felicit?ri: a?i realizat integritate conceptual? la nivel de clas?. Acum face?i acela?i exerci?iu la nivel de namespace ?i modul (ar?tând doar interfa?a public? a modulului).

La nivel de sistem, lucrurile devin tot mai complexe. Ports and adapters ?i microservices sunt unele dintre modelele care u?ureaz? integritatea conceptual? la nivel de sistem. Dar nici o solu?ie nu este perfect?, fiecare dintre ele are dezavantaje .

Un avertisment: integritatea conceptual? este foarte greu de ob?inut, mai greu decât g?sirea de nume potrivite. Cu toate acestea, experien?a m-a înv??at c? atunci când reu?e?ti, integritatea conceptual? este nu numai foarte util?, dar ?i frumoas?. Într-o lume plin? de bug-uri ?i cod urât, frumuse?ea poate face minuni pentru moralul t?u.

Pentru a face software design mai bun, str?duie?te-te s? ob?ii integritate conceptual? la nivel de clas?, namespace, modul ?i de sistem.

Întrebarea de reflec?ie: Ce p?r?i din aplica?ie au integritate conceptual?? Alege o clas? la care lucrezi; cum o po?i aduce mai aproape de integritate conceptual??

Vrei s? înve?i mai multe despre software _design_?i arhitectur?? E?ti interesat de ultimele practici în industria de IT software precum: DevOps, Microservices, Technical Leadership, Technical Strategy, etc.? Vino pe 28 - 29 Mai, la I T.A.K.E. Unconference s? faci parte din comunitatea european? desoftware craftsmen ?i practicieni experimenta?i.

Sursa: todaysoftmag.ro