Pse Git-Push nuk eshte metrike e performances

Publikuar: Sot, 09:12

Ne punen time te perditshme si zhvillues Backend, shpesh me eshte dashur te navigoj (dhe debatoj si rezultat) midis logjikes komplekse te punes (dhe serverit), dhe pritshmerive te menaxhimit. Frymezimi per kete shkrim erdhi duke vezhguar nje dinamike qe perseritet shpesh: krahasimin e pajustifikuar midis ritmit te punes ne menaxhim ku idete dhe kerkesat jane te perditshme dhe shpesh te paorganizuara, ne Frontend ku ndryshimet vizuale gjenerojne aktivitet te shpeshte, dhe procesit te Backend-it ku bej pjese vete. Kjo eksperience me ka vertetuar se shume drejtues projektesh bien ne gracken e numrave, duke besuar se volumi i veprimeve ne Git pasqyron produktivitetin. Por, nga ajo qe kam pare pas perdeve te sistemeve qe ndertojme, ky eshte nje keqkuptim qe demton cilesine e kodit dhe krijon presion artificial mbi ekipin.

Per te kuptuar kete qasje te gabuar ne pune, duhet te zhvendosim vemendjen nga "sa shpesh" dergojme kod, te "cfare" po zgjidhim realisht.

1. Zhurma nuk eshte Sinjal

Ne inxhinierine software, ekziston nje dallim i madh midis aktivitetit dhe produktivitetit. Nje historik i mbushur me push-e mund te jete thjesht zhurme - rregullime te vogla pasigurie, tentativa te deshtuara, ose thjesht nje stil pune i fragmentuar.

Aktiviteti: 50 push-e per dy dite, per te rregulluar pozicionimin e nje elementi.
Produktiviteti: Nje push i vetem qe implementon nje algoritem kompleks perllogaritjeje ose nje skeme te re sigurie qe ka kerkuar ore te tera analize.

2. Gabueshmeria e matjes sasiore

Te matesh performancen me Git Push eshte si te vleresosh nje autor nga numri i fjaleve qe ka fshire dhe rishkruar, ose nje arkitekt nga numri i skicave qe ka hedhur ne kosh.

Se pari, reflektimi eshte pune. Programimi eshte 70% mendim e analize, dhe 30% shkrim kodi. Nje inxhinier qe kalon 4 ore duke lexuar dokumentacion ose duke optimizuar nje query SQL per te shmangur renien e serverit, po prodhon vlere kolosale, edhe pse grafiku i kontributeve mbetet i pandryshuar per ate periudhe.

Ka nje thenie ne boten e programimit; qe "Kodi me i mire eshte ai qe fshihet". Ndonjehere performanca me e larte tregohet kur nje zhvillues fshin 200 rreshta kodi te panevojshem dhe i zevendeson me 10 rreshta efikase. Sipas logjikes se numrave dhe push-eve, ky inxhinier do te dilte me performance negative.

3. Rreziku i Lojes me Sistemin

Kur nje metrike behet objektive, ajo pushon se qeni nje metrike e mire (Ligji i Goodhart). Nese inxhinieret e dine qe vleresohen nga numri i push-eve dhe dokumentacioneve, atehere ata do te ndajne ndryshimet ne fragmente atomike te pakuptimta, do te dergojne kod te patestuar mire vetem per te ngjyrosur grafikun, dhe do te shmangin detyrat komplekse qe kerkojne kohe dhe nuk prodhojne statistika te menjehershme. Perfundimi? Kosto kohore, teknike e keqe, mundesi deshtimi total ne fund.

4. Cfare duhet te matet realisht?

Ne vend qe te numerojme se sa here eshte perdorur terminali apo sa i gjate eshte bere dokumentacioni, vemendja duhet te kthehet te rezultatet e prekshme:

Lead Time for Changes: Sa kohe duhet qe nje ide te kthehet ne kod funksional ne produksion?
Change Failure Rate: Sa perqind e dergesave rezultojne ne gabime qe kerkojne nderhyrje te menjehershme?
Vlera e Biznesit: A e zgjidh ky kod problemin e perdoruesit? A eshte sistemi me i shpejte, me i sigurt dhe me i shkallezueshem?

Si perfundim, duhet te them se produktiviteti i vertete matet me zgjidhje, jo me goditje te tastieres. Nje kod i paster, i miremenduar dhe qe nuk kerkon mirembajtje te vazhdueshme vlen shume me teper se nje lume push-esh qe vetem shtojne kompleksitetin e projektit.

Si zhvillues, fokusi yt duhet te mbetet te cilesia dhe integriteti i sistemit. Ne fund te dites, suksesi i projektit nuk varet nga dokumentimi i tij, por nga qendrueshmeria e produktit qe dokumentohet. E di qe kjo do jete nje sfide e vazhdueshme me cdo projekt-menaxher te ri qe do kesh. Keshilla ime finale? Balance!