Salut, am sa incerc eu un raspuns care este mai mult o opinie personala decat ce se intampla acum in industrie.
Raspunsul pe foarte scurt este ca orice mod de organizare a activitatilor de dezvoltare e bun atata vreme cat acest mod este privit ca un instrument si nu ca un scop in sine, atata vreme cat nu se face abuz (al doilea motiv deriva cumva din primul).

In opinia mea toate chestiile de genul TDD, agile, sprint, scrum, kanban sunt niste mizerii. Ele in sine nu sunt asa si toate au pornit de la o idee buna, de la un scop nobil. Insa dupa cateva succese mai mult sau mai putin locale s-a incercat de fiecare data extrapolarea folosirii acestora la nivel mare unde au esuat de obicei lamentabil. Din pacate insa ele isi mai au utilitatea inca in practica din cauza nivelului scazut de pregatire al programatorului. Sa ma explic, drept pentru care am sa ma imitez mai precis la TDD.

A aplica TDD ca la carte (acum mai depinde si care care e citita), nu e un lucru rau in sine, cum de altfel nici neaplicarea lui. Orice forma de organizare a codului si efortului de programare este o chestie buna in principiu atata vreme cat nu ajung sa devina scopuri. De exemplu atata vreme cat nu ajungi sa iti spui chestii de genul: "ne-am propus 78% test overage si avem numai 70%". Intr-un asemenea scop, chiar si prezenta unei cifre este idioata in sine. E o vorba care spune foarte clar, si pe care am trait-o pe propria piele care zice ca "ceea ce doresti aceea vei obtine". In cazul nostru vei obtine probabil un "78% test coverage" si asta e tot. Nu vei obtine cod mai bun, mai stabil sau mai clar. Ci pur si simplu un procent. Motivul principal esre acela ca depinde foarte mult ce tip de cod scrii. Altfel spus una este sa scrii un arbore inversat in care sa tii termeni pe disc si sa ii cauti in diverse moduri si alta e sa scrii o aplicatie care trage ceva din db si arunca undeva pe ecran acele lucruri. In primul caz discutam de un algoritm, de un anumit contract intre cel care implementeaza acel algoritm si cel care il foloseste. In al doilea discutam de punerea cap la cap de cele mai multe ori a unor obiecte cu alte obiecte in cadrul unui framework. Acesta e primul motiv pentru care propunerea unei cifre pentru coverage e absolut idioata - nu poti masura intr-un mod util.

Un al doilea motiv este cat de bine este progatit este programatorul. Exista o mare foame de programatori in ziua de astazi, foame care se datoreaza, in propria mea opinie, nivelului din ce in ce mai scazut al progatirii din scoala si de acceptare la angajare din partea firmelor. De o buna vreme incoace a inceput sa se confunde programarea cu manuirea in cunostinta de cauza a unui limbaj de programare (unul, mai multe, aici intra si tehnologiile). O alta vorba zice ca un programator prost creaza alte doua locuri de munca. Si nu e departe de adevar. De aici, cred eu, si inflatia aceasta de instrumente prin care incerci sa tii lucrurile sub control.

Eu am ajuns la concluzia ca e bun pentru cateva chestii punctuale. Cand ai de scris o componenta/algoritm care trebuie sa faca ceva anume si vrei sa te asiguri ca face ce ar trebui sa faca si ca pe viitor modificarile sunt compatibile semantic. Mai sunt bune pentru a arata in practica cum anume sa se foloseasca un anumit lucru (nu ca scop in sine de documentare, ci pentru a pune cap la cap ceea ce intr-o documentare este prea verbose). Pentru a verifica anumite compatibilitati sau criterii de performanta atunci cand este posibil. Este probabil sa mai fie si alte motive, acestea sunt cele pe care le-am intalnit cel mai des.

Si ajungem in fapt la ideea centrala. Dijkstra zice ca cel mai important lucru este intelectual managebility. Adica asa cum inteleg eu, sa stapanesti/controlezi din punct de vedere al intelegerii propriul cod (al tau sau cod al unui grup). Daca cineva ar citi atent aceste carti despre TDD, Agile etc si-ar da seama ca ele au avut succes numai cand programatori erau bine pregatiti. Ce numesc eu un programator bine pregatit este un programator care isi pune intrebari, lucru care mi se pare esential. Complet diferit fata de specia care se apuca sa faca ce i se pare bun, in cea mai mare viteza daca se poate. Concluzionand si rezumandu-ma la propria mea experienta de lucruri in companii diverse (sunt peste 15 ani de cand am vazut tot soiul de chestii), echipele bune isi fac propriile reguli, care de cele mai multe ori seamana cu cele din carti. Echipele slabe, hoardele, isi propun sa aplice by the book, isi antreneaza angajatii sa aiba centuri negre in scrum, kanban si sfarsesc tot prin a avea un cod pe care nimeni nu doreste sa se uite, primii fiind ei. Cred ca ar trebui fiecare sa se concentreze in a isi exersa propria judecata, in a pune la indoiala orice, in a incerca sa faca el lucrurile si mai apoi orice forma de organizare a codului sau a programarii poate fi buna.

PS: Nu am avut ocazia sa lucrez pentru marii din domeniu, Google, Facebook et co, dar cred ca lucrurile stau cam asa si acolo.

Introducerea limbajului Java reprezinta unul din principalele noastre obiective pe partea de development.

http://infoarena.ro/development

Aveti vre-o estimare cu privire la acest lucru? Stiu ca tot ce faceti este voluntar si apreciez enorm acest lucru. Vreau doar sa imi fac o idee.
Eu am lucrat acum cativa ani (multi ani) in urma cu C++, dar am uitat aproape complet. Am incercat sa ma pun la punct. Dar la fiecare participare la cate un concurs pe aici am trait mereu frustrarea de a muri cu ideile bune in mana fiindca consumam timp ba sa sortez o treaba, ba ma trezeam ca seturile se comporta altfel decat imi imaginam, ba ca uitam cate o initializare cu 0 sau mai stiu eu ce alte prostii. De aceea am si renuntat sa mai particip cumva, pentru ca nu vad nici un beneficiu in a consuma zeci de ore pentru a ma pune la punct in C++ de exemplu, cand in Java nu pierd nici o fractiune de secunda cu nedumeriri de implementare.

Salut,
Stiu ca s-a mai discutat dar am vazut ca mesajele despre acest lucru sunt destul de vechi. Luati in calcul si adaugarea Java? Ma ofer sa ajut cu integrarea lui daca este cazul. Nu stiu ce chestii se folosesc pe acolo dar imi imaginez ca nu poate fi chiar atat de greu.
Multumesc

Pai momentan cel mai mult infoarena este folosit pentru pregatirea pentru olimpiada de informatica, la care limbajul de programare este C++ . Nu stiu cati useri care sunt acuma pe site si-ar dori mai bine sa lucreze in Java (probabil doar pentru a invata chestile de baza, nu pentru a rezolva probleme complicate in java) . Nici pe topcoder nu cred ca sunt multi romani care codeaza in java...

Asa este. In umila mea opinie insa acesta e un lucru care trebuie schimbat. Schimbat nu in sensul de a fi inlocuit, nici pe departe. Ci in sensul de a fi imbogatit. De a atrage cat mai multi oameni in a ramane implicati in acest fenomen.

Nu stiu despre povestea cu 0ms, dar cred ca la punctajele partiale nu primesti punctele fiindca testele sunt grupate. Mai precis, pentru ca sa primesti punctaj pe o grupa, trebuie sa fie ok toate testele din respectiva grupa.

Salut,
Stiu ca s-a mai discutat dar am vazut ca mesajele despre acest lucru sunt destul de vechi. Luati in calcul si adaugarea Java? Ma ofer sa ajut cu integrarea lui daca este cazul. Nu stiu ce chestii se folosesc pe acolo dar imi imaginez ca nu poate fi chiar atat de greu.
Multumesc