NjĂ« nga profesionet mĂ« tĂ« mbingarkuara me idiotĂ« janĂ« menaxherĂ«t qĂ« drejtojnĂ« programuesit. Jo tĂ« gjithĂ«, por ata qĂ« vetĂ« nuk kanĂ« qenĂ« kurrĂ« programues. Ata qĂ« mendojnĂ« se efikasiteti mund tĂ« ârritetâ (apo tĂ« rritet âefikasitetiâ?) me metoda nga librat. Madje pa u lodhur as tâi lexojnĂ« kĂ«ta libra â se fundja ka edhe ndonjĂ« video mashtruese.
Ata qĂ« nuk kanĂ« shkruar kurrĂ« kod. Ata pĂ«r tĂ« cilĂ«t bĂ«hen filmat hollivudianĂ« pĂ«r programuesit â po, ata ku e kontrollojnĂ« email-in nga rreshti i komandĂ«s. Ata qĂ« nuk i intereson asgjĂ« tjetĂ«r pĂ«rveç treguesve, afateve dhe pagĂ«s sĂ« tyre.
Ata që janë shumica.
Por idiotë janë për një arsye tjetër. Ata duan efikasitet, ose të paktën rezultatshmëri (hajde, menaxher, kërkoje në Google dallimin), pa kuptuar as njërën, as tjetrën. Pa e kuptuar fare thelbin, procesin e arritjes së rezultatit, humbjet që ndodhin gjatë këtij procesi, kostot e zhvillimit. Me pak fjalë, duke punuar me programuesin si me një kuti të zezë.
Janë turrur të menaxhojnë programues vetëm për një arsye: këtu ka bujë, para, treg dhe një grumbull idiotësh si vetja. Ka ku të humbasin mes turmës.
Sikur buja tĂ« ishte nĂ« prodhimin mekanik e tĂ« montimit, do tĂ« vraponin andej. ĂfarĂ« universalĂ«sh tĂ« dĂ«shtuar. Sâdo tĂ« habitesha fare nĂ«se tipi qĂ« shet bredha nĂ« lagjen tonĂ« nĂ« dhjetor Ă«shtĂ« njĂ« menaxher IT me pushime.
Me pak fjalë, nëse keni mundësi, largojini sa më parë këta tipa. Mos u shqetësoni, ata do ta gjejnë një punë. Asnjëri prej tyre nuk do të bëjë kurrë diçka të hajrit, derisa të bëhet vetë programues. Sepse nuk e kupton thelbin, mekanizmin dhe logjikën e procesit që menaxhon.
Mirë, kaq për menaxherët. Tani te thelbi, për programuesit. Si të rritni efikasitetin e zhvillimit duke mësuar të shkruani kod cilësor.
QĂ« tĂ« rrisni efikasitetin, duhet tâi zgjidhni detyrat mĂ« shpejt pa humbur cilĂ«sinĂ«. QĂ« tâi zgjidhni detyrat mĂ« shpejt, duhet tĂ« dini tĂ« shkruani menjĂ«herĂ« kod cilĂ«sor. Edhe âcilĂ«sorâ, edhe âtĂ« shkruaniâ, edhe âmenjĂ«herĂ«â. Po e shpjegoj me njĂ« metaforĂ«.
Të shkruash kod cilësor është si të flasësh saktë në një gjuhë të huaj. Kur nuk e di gjuhën, humbet një mal me kohë duke u përpjekur të formulosh mendimet e tua në të.
Nëse duhet të thuash diçka urgjentisht, thjesht ngjit ca fjalë çfarëdo, shpesh jo ato që duhen, harron nyjat, rendin e saktë të fjalëve, pa folur fare për kohët e foljeve dhe shqiptimin e mjerë.
Nëse ka kohë për të formuluar përgjigjen, atëherë do të duhet të hapësh fjalorin ose përkthyesin online dhe të humbësh një mal me kohë për të shprehur mendimet e tua. Ndjesia, megjithatë, prapë do të jetë e pakëndshme: e thua përgjigjen dhe nuk e di nëse është e saktë apo jo. E njëjta gjë ndodh me kodin: duket sikur e shkrove, duket sikur funksionon, por nëse është cilësor apo jo - kush e di.
Del një humbje e dyfishtë kohe. Kohë harxhohet për të menduar përgjigjen. Kohë harxhohet edhe për ta formuluar atë përgjigje - dhe jo pak.
Nëse, përkundrazi, ekziston aftësia për të shkruar kod cilësor, atëherë përgjigjen mund ta formulosh menjëherë, sapo të jetë pjekur në kokë, pa humbur kohë shtesë me përkthim.
AftĂ«sia pĂ«r tĂ« shkruar kod cilĂ«sor ndihmon edhe nĂ« projektimin e arkitekturĂ«s. Thjesht nuk do tâi marrĂ«sh fare nĂ« konsideratĂ« nĂ« mendje variantet e gabuara, tĂ« parealizueshme ose tĂ« bĂ«ra keq.
Si përfundim: aftësia për të shkruar kod cilësor e përshpejton ndjeshëm zgjidhjen e detyrave.
Por kjo nuk është e gjitha. Falë menaxherëve të paaftë, ka edhe një pengesë: në thelb, ne nuk kemi asnjë arsye të shkruajmë kod cilësor. Menaxheri nuk e sheh kodin, klienti nuk e sheh kodin. Kodin ia tregojmë njëri-tjetrit rrallë, vetëm ndonjëherë, në disa projekte ku ka një person të caktuar për rishikimin e kodit ose bëhet refaktorim periodik.
Si rezultat, në shumicën e rasteve kodi i keq shkon në production ose te klienti. Te personi që e ka shkruar krijohet një lidhje e qëndrueshme nervore: kod të keq jo vetëm që mund të shkruash, por edhe duhet - e pranojnë, madje edhe të paguajnë për të.
Në fund, aftësia për të shkruar kod cilësor praktikisht nuk ka asnjë shans të zhvillohet. Kodin e shkruar nga një punonjës i zakonshëm nuk e kontrollon askush, kurrë. Arsyeja e vetme pse ai do të mësojë të programojë siç duhet është motivimi i brendshëm.
Por ky motivim i brendshëm bie ndesh me planet dhe kërkesat për efikasitet dhe produktivitet. Dhe ky kundërshtim zgjidhet qartazi jo në favor të kodit cilësor, sepse për kod të keq as nuk qortojnë. Ndërsa për mosrealizimin e planit - po, madje shumë.
Si vepruar? Unë shoh dhe propozoj dy rrugë, të cilat mund të kombinohen.
E para Ă«shtĂ« tâia tregosh kodin tĂ«nd dikujt brenda kompanisĂ«. Jo nĂ« mĂ«nyrĂ« reaktive (kur ta kĂ«rkojnĂ« ose tĂ« detyrojnĂ«), por proaktive (hej, shikoje pak kodin tim, tĂ« lutem). KĂ«tu kryesorja Ă«shtĂ« tĂ« mos e zbusĂ«sh kritikĂ«n dhe tĂ« mos pĂ«rpiqesh ta mbĂ«shtjellĂ«sh me mirĂ«sjellje artificiale. NĂ«se kodi Ă«shtĂ« i dobĂ«t, duhet thĂ«nĂ« troç: kodi Ă«shtĂ« i dobĂ«t. Sigurisht, me shpjegime dhe rekomandime se si mund tĂ« bĂ«het mĂ« mirĂ«.
Por edhe kjo rrugĂ« ka kufizimet e veta. ZbatueshmĂ«ria e saj varet nga momenti kur ndodh kontakti. NĂ«se puna tashmĂ« ka hyrĂ« nĂ« production dhe rezulton se kodi Ă«shtĂ« i dobĂ«t, zakonisht nuk ka mĂ« kuptim tĂ« ribĂ«het. MĂ« saktĂ«, nuk ka arsye biznesi â pĂ«r mĂ« tepĂ«r do tĂ« bien edhe metrikat. Do tĂ« vijnĂ« menaxherĂ«t dhe do tĂ« tĂ« mbulojnĂ« me kĂ«rkesa pĂ«r efikasitet. Madje as mos provo tâu shpjegosh se kodi i dobĂ«t do tĂ« kthehet patjetĂ«r nĂ« formĂ«n e bug-eve â nĂ« fund do ta pĂ«sosh vetĂ«. Mbetet vetĂ«m tĂ« marrĂ«sh pĂ«rsipĂ«r qĂ« tĂ« mos e bĂ«sh mĂ« kĂ«shtu.
NĂ«se puna ende nuk Ă«shtĂ« dorĂ«zuar, ose sapo ka nisur, atĂ«herĂ« kritika e ashpĂ«r ndaj kodit (ose projektit, idesĂ« sĂ« tij) mund tĂ« ketĂ« njĂ« vlerĂ« krejt praktike â njeriu do ta bĂ«jĂ« siç duhet.
Rruga e dytë, më e forta, është të merresh me zhvillim open source në kohën e lirë. Sepse qëllimi është ky: një numër i madh programuesish, pikërisht programuesish, ta shohin kodin tënd dhe të japin mendim për të. Brenda kompanisë askush nuk ka kohë. Ndërsa programuesit anembanë botës gjithmonë do të hedhin një sy, nëse shkruan diçka vërtet të dobishme nga pikëpamja praktike.
Pika kryesore, sipas mendimit tim, është të shkruash kod jashtë orarit të punës, sepse kështu nuk do të të pengojë kontradikta mes cilësisë së kodit dhe shpejtësisë së dorëzimit të rezultatit. Mund ta shkruash zhvillimin tënd edhe për një vit të tërë. Askush nuk do të të ushtrojë presion me afate, me kërkesa teknike, me para apo me shef. Liri e plotë dhe krijimtari.
Vetëm në krijimtarinë e lirë do ta kuptosh dhe do ta ndjesh çfarë është kodi i shkëlqyer, do të shohësh bukurinë e gjuhëve të programimit dhe të teknologjive, do të ndjesh hijeshinë e detyrave të biznesit. Dhe, sigurisht, do të mësosh të shkruash kod cilësor.
Natyrisht, kjo do tĂ« kĂ«rkojĂ« kohĂ«n tĂ«nde personale. Ashtu si çdo formĂ« tjetĂ«r zhvillimi. Shihe jo si shpenzim, por si investim â te vetja.
Burimi: habr.com
