Voi fi off-topic, @iamntz te rog sa ne muti cu asta, prevad un thread interesant. Din punctul meu de vedere este o chestiune de perspectiva.
Am observat ca romanii care livreaza ceva (imperfect) si apoi il imbunatatesc sunt perceputi ca profesionisti. In acelasi timp, cei mai multi, care vor sa atinga perfectiunea din prima, nu doar ca nu o ating, dar mai mult decat atat au tendinta si sa ii critice pe ccei care misca lucrurile inainte in modul imperfect.
Revenind pe taram geek, toti developerii pe care am reusit sa-i conving sa nu mai caute perfectiunea imediata, dar sa se straduiasca mereu sa invete cum arata ea, si sa isi divizeze efortul, au ajuns sa fie extrem de bine cotati. Motiv pentru care prefer sa lucrez cu oameni care pot livra atat cod simplu (non-framework), cat si cod complex care foloseste librarii/frameworks pentru a facilita munca. Sper sa faca sens ce am zis, sunt pe fuga. Revin.
[quote=“tekkie, post:1, topic:3546”]
perfectiunea imediata
[/quote] este in termeni simpli: idealism. Cum toate limbajele de programare sunt prin excelenta leaky abstractions o astfel de abordare este doomed by default. Ar trebui ca facultatile cu profil IT sa aiba macar un curs cu tenta phy.
A livra un cod cu anumită calitate, depinde atât de nivelul de cunoștințe sau mai bine spus de experiența pe care cineva o deține, dar și de felul în care reuște cineva ca dintr-o anumită documentație sau descriere a ceea ce ar trebui livrat, să disece ceea ce ar trebui livrat pentru că are într-adevăr valoare pentru client, să înlături orice este vag și într-un final să ai o specificație care să îți permită o metodologie de lucru care duce nu doar la un cod mai bun dar și ușor de modificat/adăugat în viitor.
Dacă ai ceva mai multă experiență, atunci cred că ai mai multă încredere și că ce vei livra ceva care respectă cerințele inițiale, dar și că vei putea îmbunătăți pe parcurs.
Însă, dacă ești la început fie vei aborda problema într-un mod hacky sau vei dori să livrezi ceva mai de calitate, dar fără suport din partea unei echipe, e puțin probabil să livrezi ceva funcțional într-un timp rezonabil.
Însă dacă înainte de a scrie orice linie de cod, indiferent de nivelul de experiență, independent sau în echipă iei la puricat cerințele prin punerea de întrebări pentru, să zicem probleme ceva mai mici sau mai mari sau anumite schimbări pentru un anumit proiect, sau pentru proiecte mai complexe/mari lucrând în echipă cu metode de analiză gen ddd/bdd și în urmă cărora să rezulte un anumit workflow și scenariile descrise într-un limbaj comun și care se poate fi înțeles de orice din echipă.
În astfel de cazuri, cred că indiferent de experiență, se poate livra un cod care aduce valoare și poate fi și mai ușor de întreținut pe viitor.
Ideea mea era legata de ce ne face sa fim “romani”, de care zicea si @Bogdan_Ciubotariu. Cred ca “ai nostri” nu fac misto doar de dragul de a face asta, sau pt a se lua neaparat de capra vecinului, ci pt ca nu au cultura ducerii lucrului pana la capat, ei voind mereu sa fie perfect, sa ia ochii. Motiv pt care se tot apuca si nu termina, si atunci strugurii celui care face devin acri.
Cand eram mai neexperimentat, asteptam cam mult pana sa livrez un produs in ideea de a-l face “cat mai bine” de la inceput. Intre timp am mai evoluat (cred) si livrez “ceva” cat mai repede, dar fara sa renunt la securitate sau la bune practici. Livrez des si pe bucati, dar ma asigur ca fiecare bucata este cat mai aproape de ideal, asa cum il inteleg la acel moment.
Pentru mine, ideal reprezinta securitate cat mai ridicata, lizibilitatea codului si functionarea corecta a platformei. Cel putin astea imi vin mie acum in minte.
Totodata ma asigur ca bune practici (nu neaparat “cele mai bune”) sunt urmate deoarece sunt un adept al ideii Unchiului Bob: “the only way to go fast is to go well”. Si asta am simtit-o pe pielea mea in ultimul an de zile (in sensul bun).
Ma confrunt si eu cu asta acum, incerc sa mentin un echilibru intre perfectiunea codului si viteza de dezvoltare.
Pe de o parte am inteles cum sa scrii cod bun (DRY, single responsability, oop, cod semantic, variabile cat mai explicite, chestii de genu) si incerc sa aplic metodele astea la job, dar pe cealalta parte sacrific din viteza de dezvoltare.
Nu am destula experienta cat sa zic ca merita sa investesc mai mult in perfectiunea codului, dar cred ca este important sa pastram un echilibru intre perfectiune si viteza.
Experienta mea cu scrierea “codului bun” (toate metodele pe care le-ai enumerat) este ca am castigat foarte mult la viteza pe termen lung.
Da, am avut momente cand m-am gandit ca ar trebui sa mai sar peste cateva practici “ca sa termin mai repede”, dar apoi mi-am adus aminte de cat de urat evolueaza codul mai tarziu. Astfel ca am preferat sa pierd “acum” ceva timp, dar sa castig mai mult timp pe termen lung. Si in cazul meu chiar s-a aplicat la fiecare proiect din ultima perioada.
Din experienta mea, pot spune ca urmand bunele practici ai sa pierzi mult mai putin timp facand debugging si ai sa ai mult mai multa siguranta cand va trebui sa schimbi/adaugi ceva.
De asta eu nu cred ca este nevoie de un echilibru intre perfectiune[1] si viteza, ci sunt direct proportionale.
[1] Atat timp cat prin perfectiune intelegem acel ideal de: [quote=“alecs, post:5, topic:3546”]
securitate cat mai ridicata, lizibilitatea codului si functionarea corecta a platformei
[/quote]
S-ar putea sa fiu putin partinitor pentru ca am lucrat la proiecte destul de ample cu termen final mai mare de 6 luni (cu 1 sau 2 programatori). Nu stiu daca se aplica si la proiecte mai mici sau cu durata mica de viata. Dar consider ca atunci cand lucrezi intr-o echipa, bunele practici sunt esentiale.