Ce este documentele de design și ce vrea ei
Am bătut la cap un coleg să facă un design document și cred că nu am fost suficient de convingător în a explica la ce e bun. Încerc să remediez situația în scris și în public.
Dacă ești obișnuit cu un anumit fel de a dezvolta programe, a scrie un document de design pare pierdere de vreme. Cum adică, în loc să scriu cod cum fac ceilalți copii io stau în Word pentru o chestie pe care oricum n-o s-o citească nimeni? Și care peste două luni oricum n-o să mai țină pasul cu codul? Doar așa, de dragul birocrației? Îs super-programator, îmi ies programele perfect din prima. Design documents are for sissies, nu? Cui la ce ajută?
Ei bine, ajută la fel cum ajută fițuicile. Dacă ai petrecut timpul scriind tot ce trebuia scris pe fițuici, înseamnă că deja ai reținut informațiile respective și poți să te duci bine-mersi la examen și să lași fițuicile acasă. Știi suficient ca să nu mai ai nevoie de ele.
La fel și un document de design. Dacă l-ai scris suficient de detaliat încît să convingă pe altcineva care-l citește că știi ce trebuie făcut, că designul îndeplinește cerințele mușteriului, că te-ai gîndit la toate aspectele, că ai tratat toate cazurile, că ai considerat și alte alternative și ai ales-o pe cea mai potrivită atunci poți să și ștergi respectivul document pentru că și-a făcut treaba. Scopul nu e crearea documentului în sine, ci procesul prin care l-ai creat.
O să zici bine-bine, da' nu mai bine mă apuc să scriu direct cod? Găsesc io pe parcurs ce-mi scăpat acuma, bag un refactoring, o piruetă, pam-pam.
Aș zice că nu, pentru că:
- din cod nu reies alternativele pe care le-ai considerat și motivele pentru care le-ai respins;
- cînd scrii cod de multe ori te împiedici de obstacole de nivel jos care te fac să-ți pierzi șirul (gen „Cum o fi sintaxa pentru capturile cu nume în expresiile regulate din .NET?" sau „De ce satana nu scrie log4net unde i-am zis să scrie?”). Scrierea unui document îți permite să te concentrezi doar asupra nivelului de design;
- o eroare de design descoperită acum e mult mai ușor de corectat în Word decît dacă o descoperi după ce deja ai deployat la client.
Cît de formal să fie un document de design? Nu contează. Vrei să fie după șablonul cu antetul firmei și cele 74 de secțiuni obligatorii? N-ai decît. Vrei să aibă diagrame animate cu efecte 3D și ponei roz? Foarte bine. Nu ai decît un txt și niște poze de pe-un whiteboard? La fel de bine. Cum ziceam, important este doar procesul de gîndire al cărui rezultat este documentul de design. (Totuși, un șablon bine făcut te ajută să iei în considerare toate aspectele necesare.)
Alt avantaj e că scrierea unui document de design este un exercițiu de comunicare. Reușești să te faci înțeles? Să-ți transmiți ideile celei care citește documentul? Reușești să convingi pe toată lumea că design-ul tău e optim? Ca la orice altceva, doar prin repetiție devii mai bun și, poate paradoxal, nu poți fi un bun programator fără a fi un bun comunicator (în fond, programele sunt scrise în primul rînd pentru alți oameni și abia apoi pentru calculatoare, dacă am vrea să scriem pentru calculatoare am scrie în assembler).
Toate bune și frumoase, pare corect tot ce zic, mai că v-am convins, nu? Doar că avem niște probleme. Una e că suntem, ca programatori, leneși și, în lipsa unei forțe exterioare, decît să facem ceva care nu e scris cod, mai bine nu facem. Soluția este, cred, ceea ce s-ar numi „team (& company) culture": dacă toată lumea din echipă face asta, dacă așa e obiceiul, fac și eu. Cum să creezi o asemenea cultură acolo unde nu există? Habar n-am. Poate ajută dacă scrii pe un blog pe care nu-l citește nimeni, nici măcar nevastă-ta? :)
Și apoi, chiar dacă există o asemenea cultură, entropia și presiunea datelor limită (na, ziceți voi mai bine „schedule pressure" pe românește) o fac foarte fragilă, una-două se revine la status-quo. E ca la flori, dacă n-o uzi se ofilește
Îmi cer scuze în mod oficial pe această cale metaforelor care au fost maltratate în alcătuirea acestui text.
