Code refactoring should not be done just because we can

Sunt foarte confuz în ceea ce privește declarația din titlu. Cu atât mai mult cu cât vine din partea celui mai folosit CMS.

Pe de-o parte, am fost învățat că este bine să cureți codul de fiecare dată când vezi o modalitate de a face ceva mai eficient sau mai clar.

Pe de altă parte, când ai un sistem folosit de milioane de oameni, poate că nu e o idee bună să intri cu buldozerul în cod…

De unde și confuzia :slight_smile:

Se procedează bine? Se procedează rău?

1 Like

Nu stiu daca e bine sau rau, stiu ca eu fac de fiecare data “refactoring” pentru ca atunci cand lucrezi la o functie, observi ca respectiva functie/modul nu se leaga cum trebuie in codul existent, sau poate ca exista un mod mai optim/mai logic/mai bun si asa ajungi sa refaci mult mai mult decat ti-ai propus initial.

Eu sunt un freak in ceea ce priveste organizarea codului, totul trebuie sa fie exact intr-un mod anume, liniile de cod impartite la maxim 100 caractere, indentarile cu tab, blocurile if/else intr-un mod anume (si asta doar din punct de vedere al aspectului codului, nu vorbesc de functionalitati). Dar cred ca e bine dupa cativa ani de experienta sa-ti pui amprenta ta asupra codului.

1 Like

Mie mi se pare că, exceptând situațiile în care refactoring-ul este neapărat necesar pentru că e un cod de f proastă calitate, totul se reduce la costuri. Ai bani/timp să faci refactoring-ul ăla sau nu? :slight_smile:

Nu e vorba de timp de făcut. Am aflat de politica asta după ce am trimis un patch ce nu făcea altceva decât sa curețe și să separe din responsabilități metodele din clasa respectivă (dacă voiai să extinzi clasa respectivă ar fi însemnat să copiezi o grămadă de cod dintr-o parte în alta…).

Chiar dacă mi s-a sugerat că s-ar putea accepta un astfel de patch, sunt un pic… descurajat de această politică. :slight_smile:

1 Like

Eu vorbeam la modul general, nu neapărat vizavi de WP :smiley:

La modul general (romanesc as putea spune) clar e vorba de costuri. Dar la modul virtual, teoretic, e bine sa rescrii codul daca ti se pare ca ceva nu e logic sau la locul lui. In proiectele open-source, e decizia liderilor de proiect, si indiferent daca e buna sau rea, e decizia lor si punct.

@iamntz daca te mananca sa te bagi la WP … pfff, sa-ti fie invatatura de minte :smiley:

Da, că prin străinătățuri umblă câinii cu cuvrigi în coadă și o să ți se aloce ție bugete pentru că nu-ți place cum e indentat codul… Să nu exagerăm, totuși…

2 Likes

Code refactoring presupune doar indentare? Hai sa o luam asa:

Cati din cei care citesc topicul asta si lucreaza intr-o companie din Romania au cerut sau li s-a cerut sa faca refactoring intr-o aplicatie deja existenta, din motive pur estetice sau de viteza? Nu vorbim de considerente de functionalitate, ala nu e refactoring, e debugging.

Nota: asta nu ii implica pe cei care sunt juniori si le este cerut sa refactorizeze ceva DOAR pentru a se obisnui cu (virgula) codul deja existent.

(hai sa lasam Romania sau restul deoparte, nu e vorba doar de companii romanesti (cele mari sunt probabil conduse oricum de straini) ci mai mult de modul de gandire (de nenumarate ori cand lucram ca project manager mi se cerea sa fac o estimare de costuri/timp pentru refactoring, pentru ca apoi sa fie respinsa pe motiv de costuri prea mari) Intelegeti ideea? “Timp avem cacalau, cu banii stam mai prost.”)

1 Like

Eu sunt de părere că refactor ar trebui să faci în bugetul alocat, atât ca timp cât și ca bani.

Hai să luăm metafora geamurilor sparte: dacă ți se sparge un geam în casă cum procedezi? Îl schimbi imediat sau începi să trasezi planificări, bugete etc. Îl schimbi atunci sau îl pui în calendar „luna viitoare, pe 18”?

La fel e și cu codul: vezi ceva ce nu e în regulă sau ceva ce ar putea fi scris mai bine? Te apuci și faci asta (mai puțin în WP, unde patch-ul va fi respins :smiley:). Nu ai destul timp pentru asta? Faci azi puțin, mâine puțin șamd.

Mi se pare ciudat să ceri bani pentru refactor. Nu știu cum sunt clienții voștri, dar pe ai mei îi interesează prea puțin calitatea codului, că se repetă, că e indentat cu spații sau cu tab-uri, că urmează PSR2 sau nu, ca am metode de 10 sau 500 linii, că am sau nu claritate în numirea claselor/metodelor/variabilelor șamd.

Fac refactor în primul rând pentru mine. Mai ales dacă sunt șanse ca eu să fiu cel ce întreține acel cod. Chestia asta, pentru client, ar trebui să fie invizibilă.


Faci cherry picking și sunt convins că ai înțeles ce a vrut să spună @Bogdan_Ciubotariu mai sus. :slight_smile:

Bineinteles ca am inteles :slight_smile:

Perfect de acord, asta este realitatea, dar in felul asta nu ti-e frica (virgula) ca te plafonezi? In felul asta poti scrie tot codul pe o linie, intr-o singura functie ruleaza_d_aici_sa_moara_fratii_mei(), dar ce spune asta despre noi ca programatori? Clientului i se rupe, de acord.

Făcând refactor sau scriind cod cu picioarele?

S-a întâmplat de multe ori să primesc cod scris de alții. De fiecare dată am încercat să fac modificări rapide și să termin. De fiecare dată s-a întâmplat una din următoarele:

  • cod duplicat în mai multe locuri. Am avut acum câțiva ani un CSS ce avea aceleași elemente definite iar și iar pentru fiecare pagină: .contactHeader, .checkoutHeader, .forgotPasswordHeader șamd. Toate erau identice, fără sass, fără vreun preprocesor. CSS chior. Evident că am renunțat să modific în 30 locuri și am făcut refactor…
  • cod atât de cuplat încât schimbam ceva în clasa User și avea efect în clasa MediaGallery sau Search;
  • clase atât de lungi încât mă plictiseam să fac scroll (am avut metode cu 500+ linii)
  • etc.

Din punctul de vedere al clientului totul era OK. Totul era într-un echilibru foarte fragil, dar totul era funcțional…

Tocmai de asta refactor ar trebui sa fie o chestie invizibilă pentru client…

1 Like

Scriind cod cu picioarele, scuze, nu am fost prea detaliat, sunt cu ochiul in alta parte :slight_smile: