Senior cu țâșpe ani experiență. Nu caut nimic, doar mă laud

Senior cu țâșpe ani experiență. Nu caut nimic, doar mă laud

Vârsta m-a învățat că e mai bine să țin pentru mine toate remarcile acide referitoare la codul scris de altcineva. Asta pentru că lucrez într-un domeniu ce avansează constant, iar codul scris de mine acum o jumătate de an nu este doar legacy ci este o mizerie. În plus, nu vreau să fiu ca meseriașii ăia care vin, se uită, și trântesc un „șefuuuuleee, cine ți-a făcut aici și-a bătut joc de mata!”.

Doar căăăă…. Trebuie să fac o abatere de la regulă.

Povestea e așa: o firmă la care lucrează un amic a angajat acum vreo doi ani un senior nu-știu-de-care, cu scopul exclusiv de a dezvolta un mic magazin. Din motive necunoscute, managerii au refuzat o soluție open source, adaptată la propriile nevoi și a ales calea aventurii. În loc să aibă magazinul up & running în 1-2-3 luni, încă mai lucrează la el (și mi s-a șoptit că nu pe bani puțini), dar este live.

Din motive de confidențialitate nu pot da prea multe exemple de cod, dar să zicem că dacă s-ar lua cele mai cunoscute cărți de code quality sau best practices, ar bifa absolut toate regulile. Le-ar bifa la „nu facem așa”, să ne înțelegem. Pornind de la premisa că se folosește un framework MVC (avem ORM și responsabilități bine definite), avem următoarele exemple:

  • Cele două controllere de 1500+ linii. Da, două: unul pentru backend, unul pentru frontend. Nu separarea responsabilităților, nu nimic. Dar asta nu ar fi o problemă dacă…
  • Cea mai lungă metodă dintr-un controller are ~500 linii;
  • Logica nu ar fi… tot în controller. Relații între modele? În controller, unde altundeva?
  • Că tot veni vorba, știi cum sunt relațiile definite? Ai putea crede că se folosește de framework, definește relații și lasă frameworkul să facă treaba. Ahahaha, nu. E plin de join-uri și interogări manuale. Un exemplu (printre cele mai simple interogări):

  • DRY? Pe naiba, este cod repetat de zici că s-a bâlbâit programatorul în scris!
  • Am zis că-i MVC? Ei bine, unde crezi că mai este logică? Evident, evident că și în views! Dar hei, și reciproca e valabilă: avem markup html în… controller.
  • Nu mă iau și de coding style, că e futil. Avem indent cu tab și cu spații, în unele locuri avem alinieri, în altele nu, avem camelCase dar și snake_case.

(în cazul în care te întrebi: chiar și codul nou, scris în ultimele săptămâni, arată cam tot așa, deci nu poți să zici „știi, încă învăța”)


Are rost?

De fiecare dată când întâlnesc cod scris în felul ăsta mă întreb: chiar are rost să-mi bat capul să învăț lucruri? Magazinul de față funcționează bine-mersi, aduce venituri, firma e pe profit, singurii deranjați de aceste probleme sunt doar… programatorii. Și nici măcar toți programatorii, ci doar unii mai ciudați…

Am înțeles demult (dar greu) că pe client îl interesează prea puțin cum e scris codul, cât timp îi funcționează fără (prea mari) probleme. Dar chiar așa să fie? Chiar ar trebui să renunț la a-mi păsa? Nu pot. Nu vreau să îmi fie rușine să arăt vreun proiect la care am lucrat știind că n-am dat ce am avut mai bun.

Dar mă rog, poate că sunt eu defect.

6 Comentarii

Mălin a scris

E normal ca un client să gândească în felul ăsta. Clienții sunt atehnici și chiar și aia care înteleg noțiuni tehnice de bază sunt incapabili să interpreteze un cod și să decidă dacă-i scris bine sau mai puțin bine.
Cât timp codul respectiv face ceea ce și-au dorit ei și funcționează fix așa cum și-au dorit ei nu e nicio problemă.

Cristi N a scris

Acum vreo 2 ani incepusem un proiect pentru cineva din afara, proiect la care a trebuit sa renunt pentru ca jobul de zi incepuse sa devina mai demanding si cand ajungeam acasa nu mai aveam nici un chef sa mai fac freelancing + cerinte out-of-initial-scope din ce in ce mai multe. Cum ai spus si tu, codul de atunci nu era cel mai bine structurat si erau cu siguranta lucruri ce puteau fi imbunatatite, dar respecta MVC si destul de mult SOLID. Inainte de predarea proiectului am stat cam 3 sapt sa ii prezint codul si ce directie aveam in vedere cand am facut ce am facut in proiect noului programator, iar tipul ce a preluat proiectul a lucrat foarte fain in acele 3 sapt. Fast-forward 1 an si primesc mesaj de la owner sa ma intrebe daca as fi interesat de ceva part-time pe intretinere si bug-fixes pe acel proiect. Cu ocazia asta am aflat ca tipul a renuntat la omul ce venise dupa mine cam la o luna dupa plecarea mea, si de atunci a schimbat vreo 3-4 echipe de indieni care i-au facut codul varza. Ceea ce trebuia sa fie Laravel MVC, devenise cam ce ai descris si tu. Nimeni intr-un an de zile nu a mai creat un controller nou iar view-urile erau pline de php si mysql. I declined to participate.

Paul a scris

Codul il scrii frumos nu pentru client, ci pentru tine si pentru ceilalti care lucreaza cu el.

Clientului putin ii pasa daca codul e frumos sau nu. II pasa in schimb daca iti ia o ora sau o saptamana sa rezolvi o problema critica sau sa adaugi functionalitate noua. Sau daca poate da codul si altcuiva sa lucreze cu el.

Alex a scris

Nu esti defect, boss. INSA, atunci cand bagi la foc continuu (desi nu cred ca e cazul in ce ai prezentat tu) si sari prin coduri de 4-5 proiecte pe zi, pe care e musai sa le rezolvi „ieri”, fiindca altfel iti iei mui peste mui, nu iti mai arde de cum e scris codul, ci „sa mearga”. Acelasi lucru e valabil la stil, cod (de orice fel), grafica etc si, probabil, nu doar in programare.

Adaugă un comentariurăspuns pentru

Link-urile în context sunt binevenite. Comentariile fără nume/email valid sunt șterse.
PS: Comentariul NU este editabil.

Acest sit folosește Akismet pentru a reduce spamul. Află cum sunt procesate datele comentariilor tale.

Site-ul blog.iamntz.com utilizează cookie-uri. Continuarea navigării presupune acceptarea lor. Mai multe informații.

windows apple dropbox facebook twitter