OOP PHP - Începător

wolfenste  face niste progrese notabile, pune intrebari cu cap. Cred ca dupa acest proiect va fi pe un traseu ascendent.

Am mai indrumat incepatori cu acest proiect tictactoe si incurajez pe oricine sa isi traga un mentor cu experienta.

E un proiect mic care ofera multe oportunitati de discutii, de gresit si de invatat din greseli, fara mult cod si deci fara multe regrete.

Aprob pozitiv Gasiti-va mentori!
E important sa vada si altcineva codul tau atunci cand functioneaza si crezi ca e totul in ordine. E o buna idee sa 'frecventati' comunitati cu programatori mai avansati. Deci, nu faceti asta acasa ... singuri.

In legatura cu proiectul nu stiu daca mi-as fi imaginat cum trebuie sa arate codul pentru "fa un test de integrare/incepi cu un test de integrare" daca nu as fi tras cu ochiul accidental pe proiectul lectie. Pana la urma de asta era acolo, nu conteaza ca era scis pentru alt limbaj. Cand am vazut a fost imediat clar ce mi se cere. Altfel, nu as fi reusit sa imi imaginez pentru ca nu se potriveau piesele. Nu gaseam nimic similar pe net. Peste tot testele de integrare veneau dupa testele unit. Si are sens si asa, in proiecte mari echipe diferite construiesc parti diferite care trebuie integrate de alta echipa. In plus, conditia era ca testele sa decurga in pasi mici dupa o reteta exacta: test - cod verificabil - cod verificat cu succes, abia apoi alt test. Ei bine, incepand cu testul de integrare fara a avea unitatile ajungi in situatia de a face in test extins, test de integrare, apoi unit test pentru mai multe componente si abia apoi te apuci sa scrii cod de productie care sa valideze mai intai unit test si in final testul de integrare cu care ai inceput. Nu ma plang, deja imi place asa, ma scuzam si eu de ce nu reuseam sa potrivesc piesele.

Edited by wolfenste, 18 July 2018 - 17:32.

Am zis sa nu sufar de sindromul math major si am inceput asa incetisor sa tastez cate ceva, sa-mi vina idei. Cand m-am oprit am bagat de seama ca aproape am scris toata aplicatia. Mai trebuie un view si un model. Aproape sigur nu e ce voi dezvolta in proiectul de baza cu TDD si nici nu trebuie. Am facut trei lucruri, doua bune si unul rau. M-am gandit la aplicatie si am vazut ce as putea face, am acoperit un gol (eu nu am scris pana acum nicio aplicatie oop in niciun limbaj, sa incepi direct cu TDD e cam abrupt). Partea rea e ca am cam trisat TDD-ul. Trebuie sa  mergi unde te duce TDD-ul. Acum va exista tendinta de a adapta TDD-ul ca sa potriveasca o aplicatie despre care stiu deja cum ar trebui sa fie.

Ce te impiedica sa lucrezi in fiecare zi la acest proiect? Ai griji, familie, copii, responsabilitati?

De fapt lucrez in fiecare zi. Am considerat ca imi vor veni mai usor idei pentru TDD daca voi incerca sa scriu ceva, orice. Am scris si rescris aplicatia in doua feluri si probabil ca nu e niciuna varianta acceptabila pentru proiectul propriu zis. Pare pierdere de timp dar nu este. Imi lipseste scrierea de cod oop, ori eu trebuie sa imi imaginez deja cum imi voi lega obiectele prin TDD pe cand eu nu stiu sau nu stiam cum se leaga defel. Vor fi de ajuns doar trei clase? Vreau sa fac verificarea castigatorului intr-un anumit mod, mai am oare nevoie de un obiect Square? Clasa Game primeste ca parametri doua obiecte diferite. Oare daca am inceput asa cu TDD ramane batut in cuie sau pot adauga si alti parametri? Am destule nelamuriri.

Am ratacit in unele zile mai in urma cu object analysis (tot ca sa imi dau seama cum sa scriu testele, asta era pana sa imi dau seama ca nu vom folosi asa ceva) iar acum  asa cum am mentionat am verificat cum imi pot implementa ideile). Rezultatul va fi ca odata ce am fixate niste linii mari o sa fac rapid aplicatia prin TDD. Degeaba ma gandesc eu la metode prin TDD daca nu stiu lucruri elementare mai intai. Va merge din ce in ce mai repede pe masura ce ma obisnuiesc cu obiectele. Si va merge mult mai usor la urmatoarele proiecte prin TDD.

Edited by wolfenste, 24 July 2018 - 15:05.

Cum testez metode ce nu returneaza nimic? Folosesc expectException?

Depinde de situatie. Scrie testul, si vedem daca e bun sau nu.

wolfenste, on 24 iulie 2018 - 15:04, said:

1. Nu trebuie sa iti imaginezi nimic. E chiar contraindicat. Trebuie sa faci un singur lucru: sa scrii teste care au sens. Sa alegi nume de teste (numele metodelor marcate cu @test), si sa implementezi in ele cum trebuie interactionat cu SUT in scenariul fiecarui test. Codul din test trebuie sa aiba sens dpv semantic.

Este absolut singurul tau scop.

Codul efectiv din SUT va fi doar un efect colateral. Nu trebuie sa te intrebi nici daca 3 clase sunt suficiente, nici nimic, absolut nimic.

Doar scrie teste.


2. Nimic nu e batut in cuie, lucram agil: adaugam metode, modificam metode, stergem metode, adaugam teste, stergem teste, modificam teste.

A incerca sa atingi perfectiunea din prima e o ambitie prosteasca ce iti garanteaza esecul.

A fi agil si rapid in schimbari, asta e un scop cu cap.


Deci scrie cod. Zilnic. Nu pierde timp cu analize a priori, sunt futile. Analizele si invatarea, introspectia, etc, astea se fac a posteriori.

Cititul despre teorie se face sumar a priori, in adancime a posteriori. Mai ales ca ai in mana un proiect gandit special pentru scris cat mai mult cod, aruncat cat mai mult cod la gunoi, gresit cat mai mult si invatat cat mai mult.


Degeaba citesti ce iti scriu eu aici si altii prin carti si articole. Ce citesti e fix zero barat, greselile pe care esti destinat sa le faci le vei face oricum.

Vezi de exemplu in postarile anterioare cand ti-am scris unele lucruri, si de facut tot pe dos le-ai facut.


Adevaratul invatat se face cu codul in mana, discutiile si analizele pe codul concret care e gresit.

Pune mana si commit cod gresit zilnic, daca vrei sa avansezi mai repede.

Cand tu stai si analizezi, intarzii feedback-ul de la mine cu 3-7 zile, si dupa aceste zile, acele greseli tot le faci, deci nu avansezi deloc sau de 10x mai lent.


Accelereaza bucla de feedback: cod rapid si putin, feedback-ul vine zilnic sau aproape zilnic de la mine, corectezi greselile din scurt si nu le repeti in viitor.


Ti-am spus: greseste cat mai mult si arata-mi cat mai multe greseli, ca sa pot corecta cat mai multe din ele. Arunca la gunoi mentalitatea inoculata in scoli care stigmatizeaza "a gresi".


A gresi e cel mai de valoare lucru pe care il poti face cu un mentor/profesor, in special la inceput.

Baga tare, cod zilnic.

Daca plasez pe github cod despre care stiu si eu ca e gresit, doar pun stres inutil pe mentor. Daca tot il pun, macar sa-i dau eu acceptul codului mai intai. Si e greu sa faci ceva despre care sa ai cat de cat banuiala ca ar fi corect, asa din nimic. De asta caut inspiratie pe unde pot, si asta inseamna ca pana o gasesc 'pierd' timpul pe cai de pe care nu culeg raspunsul. Departe de mine intentia sa fac ceva perfect din prima. Doar sap dupa idei.

Dar asta se colecteaza, aici aud de object analisis, acolo de acceptance testing lucruri care completeaza tabloul. Pentru mine nu e greu sa arunc in prostie cod pe github si sa las doar asta sa ma ghideze. Scriu ceva 30 min dimineata si mai vin seara sa verific cum a fost. Pe cand intre timp pot cerceta si singur destul.

Nu am mai pus nimic cateva zile pentru ca am scris aplicatia de fapt. Am facut pe dos, in loc sa imi inspire testele codul, acum imi va inspira codul testele Poate ca e gresit si o sa-l scriu iar. Dar am capatat experienta cu scrierea codului care imi va servi sa ma misc mai rapid pe viitor si totodata am primit niste raspunsuri, am mai aflat lucruri din PHP.

ps: de fapt am mers in paralel, test cases ma faceau sa ma gandesc la cum trebuie sa arate codul iar codul imi indica cum ar trebui sa arate testele (de vreme ce am deja nume de metode si tipuri de valori returnate). Inevitabil (sa zicem) cand imaginez o metoda in test case, ma mananca sa incerc sa o implementez, sa vad daca se poate. Un programator cu experienta stie deja ca sa poate si cum. Eu am imboldul insa sa merg 'in recunoastere' preventiv. Pentru ca nope experienta.

Problema: se pare ca PHPUnit nu ofera testare pentru metode ce nu returneaza nimic. E o solutie oarecum folosirea exceptiilor dar parca nu as vrea sa imi incarc codul de exceptii. Am gasit alta cale: metodele care returneaza void fac totusi ceva, modifica lucruri iar eu voi testa getters pentru acele lucruri.

Edited by wolfenste, 25 July 2018 - 16:27.

Exceptiile sunt cel mai bine create in constructorii claselor si in metode ale caror executie poate fi intrerupta lejer de un sistem extern (remote calls), asupra carora nu ai control imediat, de exemplu file upload/download, RPC, orice fel de API sau dispozitiv extern.

Existenta exceptiilor in alte locuri trebuie rationalizata mai serios, dar nu e exclusa.

Toate valorile (inputul) care intra in sistem sunt impachetate in value objects, ale caror constructori arunca exceptii in cazul in care valorile sunt invalide. Restul claselor accepta doar aceste value objects, de exemplu new Mark('X'), si niciodata doar 'X'.

new Mark('xyz') arunca o exceptie, si neavand obiectul, nu ai ce input invalid sa introduci in sistem.

Astfel garantezi ca o data ce obiectul exista, macar e valid dpv. sintactic, si in interiorul sistemului nu trebuie sa te mai preocupe validarea de acest gen, ci doar cea semantica.


Un obiect fie exista si e valid dupa creare si dupa fiecare apel de metoda publica, fie nu exista deloc. Un obiect nu trebuie sa poata fi pus intr-o stare invalida prin metodele publice.

Edited by OriginalCopy, 26 July 2018 - 06:50.

OriginalCopy, on 22 martie 2017 - 09:15, said:

Ramane valabil.

Asa sunt eu, pornesc mai greu dar nu-i nimic,  ca incetinesc ritmul pe masura ce avansez.

Edited by wolfenste, 30 July 2018 - 20:42.

wolfenste, on 30 iulie 2018 - 20:41, said:

Din punctul meu de vedere, inceputul a fost foarte lent, bucla de feedback de 3-7 zile nu e ok.

Normal bucla trebuie sa fie de maxim 1 zi.

Ca stai tu la tine in garaj si te gandesti si scrii enspe mii de linii de cod e irelevant: cat timp acel cod nu vede lumina zilei, el nu exista.

Plus ca daca vii cu enspe mii de linii de cod deodata demotiveaza: nu sta nimeni sa revizuiasca o caruta de cod deodata.

Cu imbunatatirile incrementale situatia e exact pe dos, deci cum trebuie sa fie.

Edited by OriginalCopy, 30 July 2018 - 22:23.

Got it. Atunci bucla va fi de 1 zi, exceptie zilele de sarbatoare. Cata vreme citeam sau altceva ramaneam cu impresia ca sunt in grafic.

Dupa ce ai reparat https://github.com/w...actoe/issues/14, poti trece la pasul urmator: "drilling in" pe care l-am descris anterior.

Alege unul dintre testele din TicTacToeTest, unul dintre testele mai simple, si foloseste-l pentru a ghida urmatorul proces:

Ce erori primesti cand rulezi doar acel test? Ce trebuie sa faci pentru a repara acele erori?

Daca trebuie sa creezi o clasa, scrie mai intai un unit test care testeaza construirea obiectului. Un unit test foarte scurt.

Apoi ruleaza acel unit test. Aceeasi eroare trebuie sa apara: clasa nu ai creat-o inca.

Apoi creaza clasa. Scrie cat mai putin cod posibil, strictul necesar pentru a face acel unit test verde. Poate fi si doar constructorul gol golut. Sau doar clasa gol goluta, nimic altceva, strictul necesar.

Commit: "introducing class <class>". Push.

Apoi ia urmatorul cel-mai-simplu-de-rezolvat mesaj de eroare din acelasi test de integrare. Repeta procesul de mai sus, adaugand teste intr-o clasa de test sau creand noi fisiere Test.php, dupa caz.

Commit cu un mesaj reprezentativ, push.


Rinse, repeat.


O sa observi ca, daca alegi in mod inteligent care eroare o ataci mai intai, atunci nu trebuie sa gandesti cand scrii cod in src/. Trebuie sa gandesti doar cand scrii cod in tests/, si cand alegi eroarea urmatoare pe care vrei sa o ataci.


Uneori te vei lovi de situatia in care ai gresit ceva in testele deja existente si versionate (ai uitat un detaliu, de exemplu `use`). Fa un commit separat dedicat exclusiv acelor greseli.

Gandeste-te mai intai la mesajul de commit, si apoi la codul care se potriveste acelui mesaj de commit. Nu pune niciodata cod mai mult sau mai putin de cat cere mesajul de commit pe care l-ai stabilit inainte de a scrie fie catusi de putin cod.

Vrei sa ai o corelatie 1:1 intre mesajul de commit si modificarile aduse.

Citeste cu atentie: https://alistapart.c...t-of-the-commit

Ideea e simpla: in git log trebuie sa vad lucrurile importante care se intampla in cod si de ce, semnificatia schimbarilor.

De exemplu, daca ai scris gresit un cuvant intr-un comentariu, nu trebuie sa vad in log care e acel cuvant: e un proiect software, codul conteaza, nu cosmetica.

Daca insa redenumesti o constanta, e bine sa scrii concret in log "Renamed Foo::STATUS_A -> Foo::STATUS_B". De ce? Acel log e citit de colegi. Colegul trebuie sa fie informat despre schimbarile in API, fara a trebui sa se uite prin enspe mii de linii de cod. Dar daca vrea detalii, poate vedea diff-urile oricum mai in detaliu.

Deci: gandeste-te foarte bine la mesajele de commit. Cel mai bine mai intai te gandesti la mesaj, apoi faci modificarile in cod care se potrivesc acelui mesaj. Te ajuta sa ramai focusat pe problema.
Pe termen lung, facand astfel iti antrenezi capacitatea de abstractizare, de analiza, de concentrare, etc.

Inca un mic siretlic: foloseste git add -pv. Eu de exemplu cand fac schimbari, nu reusesc sa ma tin doar de schimbarile necesare mesajului pe care deja mi l-am propus, ci mai fac mici imbunatatiri prin zonele prin care ma misc. Dar cu hunked staging apare de ca si cum as fi geniu in git log. Nu abuza de asta la inceput, incearca sa iti antrenezi disciplina mai intai.

Edited by OriginalCopy, 01 August 2018 - 15:27.

Ca fapt divers. Test: mark_is_constructed_with_value_none. Testul e trecut cu brio desi eu nu am un constructor pentru clasa Mark. De ce? pentru ca assertEquals compara null (variabila nesetata de vreme ce nu exista constructor) cu valoarea Mark::SYMBOL_NONE care este string gol. Deci testul a fost scris gresit nestiind ca assertEquals nu face o comparatie stricta.

Fun fact: dupa o sesiune de "drilling in" d-asta (cod aici: https://github.com/w...8a/src/Game.php ) te-ai ales cu cod in unele clase, si in altele nu.

Clasa Game la acel commit este goala. De ce? Pentru ca e "mai sus" in nivelul de abstractizare. Celelalte clase deja au ceva cod in ele, ceea ce inseamna ca inerent, ca rezultat al procesului TDD, ele sunt piese din puzzle mai mici, mai granulare, mai "de detaliu" in ceapa arhitecturala.

TDD te ajuta sa mirosi astfel de clase si responsabilitatile lor, in timp ce urmezi ciclul. Trebuie doar sa te obisnuiesti sa asculti ce iti spune codul despre el insusi, ca el iti spune, dar iti spune in soapta.

De aceea am spus anterior:

OriginalCopy, on 25 iulie 2018 - 10:45, said:

TDD are si partile lui rele, nu e perfect, dar e destul de bun daca ii maximizezi partile bune. In limbaje ca PHP iti trebuie si ceva mai multa (destul de multa) disciplina, in altele nu te lasa compilatorul sa faci chiar atat de multe nazbatii, dar per total, in acelasi limbaj, cu TDD e mai bine decat fara.

Sau daca o luam in ordine inversa: ce teste de integrare ai facut sa treaca cu acest cod din src/? Acele teste, chiar daca sunt "de integrare", ataca SUT-ul la un nivel din ceapa mai din mijloc.

Ei si abia acum e momentul oportun de a citi toate acele articole despre tipuri de teste, cand ai o intuitie despre ce faci: ei cand le impart in diferite tipuri de teste, o fac in mare parte pe baza adancimii la care testele ataca ceapa. PS: nu te apuca de citit, proiectul e prea mic. Apuca-te de citit si meditat cateva zile dupa ce ai terminat implementarea domeniului, si inainte de implementarea plug-in-ului web.

Edited by OriginalCopy, 03 August 2018 - 13:23.

OriginalCopy, on 03 august 2018 - 13:34, said:

E normal sa fiu condus intai catre piesele mai mici pentru ca apar ca argumente pentru alte piese mai mari.

Asa am facut si  cu tentativa aia de aplicatie. Am inceput cu dependintele ca mai apoi sa pot vedea cum trebuie sa arate clasa mare, Game. Bine, cu TDD (testul pentru) clasa Game impune niste linii generale din start.

TDD ajuta sa iti testezi codul ... daca il scrii cum trebuie. Altfel cum mi s-a intamplat mie, trec testele cand nu ar trebui sa treaca  si tot la var_dump ajung. Dar imi place ca nu imi mai trebuie browser.