Treaba asta am remarcat-o iar și iar, mai accentuat în ultimii… să zic cinci ani? Este foarte ușor să ajungi la soluții neinspirate, neavând o altă pereche de ochi care să vină cu idei.
Soluții? Ori găsești un alt programator care este în situația ta și începeți să vă criticați periodic ideile ori îți faci un forum pe care poți pune liniștit întrebări stupide, că deh, nu râde nimeni de tine, că-i dai ban
it’s easier to have bad ideas if you don’t have to explain them. And it’s impossible to get someone else’s good ideas when there’s no one else around!
Și da, testele ajută în toată povestea asta. Când pic pe un proiect legacy [1] cu teste, lucrurile sunt semnificativ mai simple. Întrebările de genul „ce a vrut autorul să spună” sunt mult mai rare și își găsesc răspuns mult mai ușor.
chiar dacă-i făcut de mine, dacă au trecut mai mult de 3-6 luni de când m-am atins de cod, este legacy. ↩︎
Deobicei testele care ajuta in situatia data, sunt cele care testeaza ca un black box, nu cele care testeaza implementarile.
Ca iti pica fisa mai repede cand vezi la ce rezultat se asteapta testul pentru un anume input.
Apoi, nu cred neaparat in “lone developer problem”, sau cel putin nu premisele de la care pleaca articolul.
Ca sa scrii cod mentenabil (a se citi, relativ simplu de inteles) trebuie sa fii un programator bun. E acelasi principiu cu cel ca daca stii foarte bine ceva poti sa il explici si unui copil de 5 ani pe intelesul lui.
Codul bun, mentenabil nu este ceva ce il scrii din prima. Faci prima data ceva ce merge, apoi iterezi designul la cod pana iti convine. E perfectionism intr-un anumit fel. Tot timpul se poate mai bine, chiar daca esti singur pe proiect.
Ce am observat e ca oamenii care au gandirea asta ca tot timpul se poate mai bine, ajung mai rapid la o versiune a codului care merge si este si mentenabila.
Si nu prea cred ca un review de cod ajuta asa de mult ca si solutie la codul scris prost. Doar imagineaza-ti un fisier de 1k linii si tu adaugi o setare sau un feature flag, modificari minore, care introduc fix 10 linii foarte mentenabile ca si modificari. Reviewerul vede cele 10 linii si zice: “Bravo, Bob! Ce cod frumos ai scris” Doar ca defapt se prea poate ca in fisierul ala sa fie haos per total si nimeni nu vrea sa recunoasca sau sa mai treaca prin el.
In final, eu cred ca trebuie sa ai 3 lucruri ca sa poti scrie cod mentenabil:
Perspectiva - ca nu o sa fii tot timpul singur pe acel proiect si ca ar trebui oricine sa poata citi codul si sa iti intuiasca intentia cu el
Mentalitate - ca tot timpul se poate curata ceva si face mai simplu de inteles
Experienta - ca sa stii unde intra in dificultate majoritatea devilor, sa vii cu un comment de ajutor sau cu un test iluminator pentru acel caz
Aici as zice ca ajuta foarte mult de faci TDD. Te obliga sa faci codu testabil din start. Eu unu scriu cod urat initial doar sa fac sa mearga, dar practicand TDD strict, iar la final il refactorizez bazandu-ma pe testele care le-am scris. Acuma eu lucrez strict UI deci cam tot ce testez e black box, poate e diferit in alte domenii
Testele sunt soluția, însă ca orice altceva, orice în excess e nociv.
Am vreo 3 proiecte personale de care m-am apucat în ultimii ani.
pipeline fain cu tot ce e mai trebuie: TDD, code style check, static code analysis (câteva tooluri), code coverage pe unit tests 100%, și vreo 70% pe integration test
un web ui pentru serverul de acasă, mai mult de monitorizare + încă ceva chestii banale, zero teste, automatic deployment, backup și cam atât
o platformă de event-uri pentru un prieten care organizează ceva event anual (LAN Party) cu vreo 50-60 oameni și care s-a tot săturat să folosească tooluri moka (gen google forms) pentru participanți chestii. Încă în faza de implementare, zero teste
După experiențele cu proiectul 1. mi-am dat seama că DHH avea dreptate. Pentru proiecte în care soluția nu e clară, unde încă mai experimenezi cu diverse abordări, testarea te încurcă. În cazul meu am scris teste pentru soluții care s-au dovedit într-un final inutile. A trebuit să șterg cod și teste la greu când am dat de un dead end cu abordarea mea. Din cauza asta proiectul încă mai zace abandonat și tot amân să mă reapuc de el. E fain să ai testare, dar vine cu un cost atașat. DHH zicea că se concentrează inițal pe funcționalitate și testarea e opțională. După ce fac totul să meargă mai adaugă teste pentru secțiune care sunt importante. Și că ei preferă integration tests vs unit tests.
Proiectul 2. l-am scris folosind unele concepte ca și în 1., însă nu am mai pus nici un requirement de testare și am putut să experimentez mai mult și unele chestii mi-au ieșit mult mai fain și mai repede. Mi-ar plăcea să scriu teste pentru anumite chestii, dar o să fac asta dacă le re-folosesc și în 1. Sunt conștient că e greu pentru cineva să înțeleagă ce e pe acolo (codul e fain structurat, însă neffind bazat pe un framework cunoscut, o să-ți ia un pic să te prinzi). Dacă nu ai experiență și disciplină abordarea asta o să conducă la mizerie de care nu vrei să te atingi. Din fericire nu a fost cazul la mine, și încă mai lucrez cu drag pe ea (2 ani+ de când am început-o). Însă poate sunt eu special, încă mai am site-uri cu cod scris prin 2006 care rulează fără probleme și pe care aș putea să lucrez oricând.
Proiectul 3 la care lucrez acum trebuie să-l predau prietenului meu după ce termin funcționalitatea (probabil în a doua jumătate a anului). Deși am zis inițial că fac totul cât mai simplu, nu a durat mult până a explodat un pic în complexitate. Se complică rapid lucrurile când vrei să ai tot ce trebuie (validări, security, xss, csrf și alt minunății). Planul actual e să-l fac să meargă, și apoi să mai petrec încă pe atât timp să-l “simplific” (abstractizări mai faine - că o să știu exact ce și cum e nevoie după ce e totul gata), să fac multe din chestiile de “core” re-usable și evident testare pentru tot ce consider “esențial”. Prietenul știe programare, dar nu foarte multă și între timp scriu și documentație la ce fac (ca pentru developeri). Avantaje: am livrat o mare parte din ce trebuia în producție în câteva săptămâni, dezavantaje: nu poate să facă mentennță la el singur (încă).
După toate experiențele astea, cred că idealul pentru astfel de proiectele ar fi să ai un pic de testare pe parcurs și să adaugi teste și să faci re-factorizare la final. Când lucrezi pe bani (fie job/fie freelance), testarea trebuie să facă parte din ce livrezi, că nimeni n-o să aștepte să re-factorizezi după ce ai făcut să meargă totul.
