En af de mest overbelastede og idiotiske specialiteter er ledere, der styrer programmĂžrer. Ikke alle, men dem der aldrig har vĂŠret programmĂžrer selv. Dem, der mener, at man kan "Ăžge" effektiviteten (eller Ăžge "effektiviteten"?) med metoder fra bĂžgerne. Uden engang at gidde at lĂŠse disse bĂžger â der er jo videoer.
Dem, der aldrig har skrevet kode. Dem, som der laves Hollywood-film om programmĂžrer for â ja, dem, hvor man ser elektronisk post gennem kommandolinjen. Dem, der kun interesserer sig for KPI'er, deadlines og deres egen lĂžn.
Dem, som de fleste af os kender.
Men de er idioter af en anden grund. De vil have effektivitet, eller i det mindste resultater (kom nu, manager, sÞg pÄ, hvad forskellen er), uden at forstÄ noget om det. De forstÄr overhovedet ikke essensen, processen med at opnÄ resultater, tabene, der sker i denne proces, eller udviklingsomkostningerne. Kort sagt, de arbejder med programmÞrer som med en sort boks.
De strĂžmmede til programmeringsledelse netop af Ă©n grund: her er der hype, penge, et marked og masser af andre idioter. Der er plads til at skjule sig.
Hvis der var hype i mekanisk fremstilling, ville de rush derhen. Universelle idioter. Jeg ville ikke blive overrasket, hvis fyren, der sÊlger juletrÊer i vores kvarter i december, er en IT-manager pÄ ferie.
Kort sagt, hvis der er mulighed, sÄ skub disse fyre ud. Bekymr dig ikke, de vil finde et job. Ingen af dem vil nogensinde gÞre noget ordentligt, fÞr de selv bliver programmÞrer. Fordi de ikke forstÄr essensen, mekanismen, logikken i processen, de styrer.
NĂ„, det er nok om ledere. Nu til sagen, til programmĂžrerne. Hvordan man Ăžger udviklingseffektiviteten ved at lĂŠre at skrive kvalitetskode.
For at Ăžge effektiviteten skal man lĂžse opgaver hurtigere uden at miste kvalitet. For at lĂžse opgaver hurtigere skal man kunne skrive kvalitetskode med det samme. Og "kvalitets", "skrive" og "med det samme". Jeg vil forklare med en metafor.
At skrive kvalitetskode er som at tale korrekt pÄ et fremmedsprog. NÄr man ikke kender sproget, bruger man en masse tid pÄ at formulere sine tanker pÄ det.
Hvis du skal sige noget hurtigt, sÊtter du bare nogle ord sammen, ofte ikke de rigtige, glemmer artikler, den korrekte ordstilling, for ikke at tale om tiderne i verberne og en dÄrlig udtale.
Hvis der er tid til at formulere et svar, mĂ„ du Ă„bne en ordbog eller en online oversĂŠtter og bruge en masse tid pĂ„ at formulere dine tanker. FĂžlelsen er stadig ubehagelig: du udtaler svaret, og ved ikke, om det er korrekt eller ej. Det samme gĂŠlder for koden â det ser ud til at fungere, men om det er godt eller ej â det ved jeg ikke.
Det bliver en dobbelt tidsfordriv. At finde pĂ„ et svar tager tid. At formulere dette svar tager ogsĂ„ tid â og det er faktisk ikke sĂ„ lidt.
Hvis man derimod har fÊrdighederne til at skrive kvalitetskode, kan svaret formuleres med det samme, sÄ snart det er modnet i tankerne, uden at bruge ekstra tid pÄ oversÊttelse.
FĂŠrdigheden til at skrive kvalitetskode hjĂŠlper ved design af arkitektur. Du vil simpelthen ikke overveje forkerte, urealiserbare eller klodsede lĂžsninger.
For at opsummere: fĂŠrdigheden til at skrive kvalitetskode fremskynder vĂŠsentligt problemlĂžsningen.
Men det er ikke alt. PĂ„ grund af projektlederne er der en anden udfordring â vi har som sĂ„dan ikke grund til at skrive kvalitetskode. Lederen ser ikke koden, kunden ser ikke koden. Vi viser sjĂŠldent hinanden koden, kun nogle gange i visse projekter, hvor der er udnĂŠvnt en «kodekontrollant» eller ved periodisk refactoring.
SĂ„ i de fleste tilfĂŠlde gĂ„r dĂ„rlig kode i produktion eller til kunden. For den person, der har skrevet den dĂ„rlige kode, dannes der en stabil neuronal forbindelse â at skrive dĂ„rlig kode er ikke kun muligt, men nĂždvendigt â den bliver accepteret, og man fĂ„r endda betalt for det.
Som fĂžlge heraf har fĂŠrdigheden til at skrive kvalitetskode slet ikke en chance for at udvikle sig. Koden skrevet af en hypotetisk medarbejder bliver ikke kontrolleret af nogen nogensinde. Den eneste grund til, at han ville lĂŠre at programmere ordentligt â er indre motivation.
Men denne indre motivation er i modstrid med planer og krav til effektivitet og produktivitet. Denne modstrid lĂžses Ă„benlyst ikke til fordel for kvalitetskode, da der ikke engang bliver irettesat for dĂ„rlig kode. Men for ikke at opfylde planen â helt sikkert.
Hvad skal jeg gÞre? Jeg ser og foreslÄr to veje, som kan kombineres.
Den fĂžrste â at vise din kode til nogen internt i firmaet. Ikke reaktivt (nĂ„r de beder om det/ tvinger dig), men proaktivt (hey, tjek lige min kode, please). Det vigtigste her er ikke at pakke kritik af koden ind i venlige vendinger. Hvis koden er skrald, siger vi det som det er: koden er skrald. SelvfĂžlgelig med forklaringer og anbefalinger til, hvordan man kan forbedre den.
Men denne vej er ogsĂ„ ikke sĂ„ god. Dens anvendelighed afhĂŠnger af, hvornĂ„r kontakten sker. Hvis arbejdet allerede er i produktion, og det viser sig, at koden er skrald, giver det ikke mening at redo. Mere prĂŠcist, der er ikke lĂŠngere grund â og resultaterne vil ogsĂ„ falde. Managerne vil komme og kvĂŠle med krav om effektivitet. Og prĂžv endda ikke at forklare dem, at skraldekode nĂždvendigvis vil komme tilbage i form af fejl â det vil ramme dig. Man kan kun tage ansvaret for ikke at gĂžre det pĂ„ den mĂ„de igen.
Hvis arbejdet derimod ikke er afleveret endnu, eller kun lige er startet, kan det at kritisere koden (eller dens projekt, idĂ©) vĂŠre helt praktisk â personen vil gĂžre det ordentligt.
Den anden vej, den fedeste â at lave open-source udvikling i din fritid. MĂ„let er jo, at en masse programmĂžrer, netop programmĂžrer, ser din kode og giver deres mening til kende. Inden for firmaet er der altid travlt. Men programmĂžrer over hele verden har ikke noget bedre at lave, og hvis du skriver noget nyttigt med praktisk anvendelse, vil de bestemt kigge ind.
Det vigtigste, efter min mening, er at skrive kode i din fritid, fordi der ikke vil vÊre nogen modstrid mellem kvaliteten af koden og hastigheden pÄ resultaterne. Brug et helt Är pÄ din udvikling. Ingen vil presse dig med tidsfrister, krav, penge eller chefer. Komplet frihed og kreativitet.
Kun i fri kreativitet vil du forstÄ og fÞle, hvad godt kode er, se skÞnheden i programmeringssprog og teknologier, fÞle glÊden ved forretningsmÊssige udfordringer. Og du vil lÊre at skrive kvalitetskode.
Sandheden er, at det vil krĂŠve, at du bruger din personlige tid. Som med enhver anden udvikling. Se det ikke som en omkostning, men som en investering â i dig selv.
Kilde: habr.com
