Et af de mest idiotiske erhverv er ledere, der administrerer programmører. Ikke alle, men dem, der ikke selv var programmører. Dem, der tror, at det er muligt at "øge" effektiviteten (eller øge "effektiviteten"?) ved hjælp af metoder fra bøger. Uden selv at bryde sig om at læse de samme bøger, er videoen en sigøjner.
Dem, der aldrig har skrevet kode. Dem, for hvem der er lavet Hollywood-film om programmører - ja, dem, hvor de ser e-mail ved hjælp af kommandolinjen. Dem der ikke er interesseret i andet end indikatorer, deadlines og egen løn.
Dem, der er flertallet.
Men de er idioter af en anden grund. De vil have effektivitet, eller i det mindste effektivitet (kom nu, leder, Google, hvad forskellen er), uden at forstå hverken det ene eller det andet. Uden generelt at forstå essensen, processen med at opnå resultatet, de tab, der opstår i denne proces, udviklingsomkostningerne. Kort sagt, at arbejde med en programmør, som om han var en sort boks.
De kom løbende ind i ledelsen af programmører af præcis én grund: Der er hype, penge, markedet og en flok af de samme idioter. Der er et sted at fare vild.
Hvis der var hype i mekanisk montageproduktion, ville vi køre dertil. Stationcars sutter. Jeg ville ikke blive overrasket over, at fyren, der sælger juletræer i vores nabolag i december, er en it-chef på ferie.
Kort sagt, hvis det er muligt, skyd disse fyre i nakken. Bare rolig, de finder et job. Ingen af dem vil nogensinde gøre noget anstændigt, før de selv bliver programmør. Fordi han ikke forstår essensen, mekanismen, logikken i den proces, han kontrollerer.
Okay, nok om ledere. Nu til sagen, for programmører. Hvordan man øger udviklingseffektiviteten ved at lære at skrive kode af høj kvalitet.
For at øge effektiviteten skal du løse problemer hurtigere uden at miste kvalitet. For at løse problemer hurtigere skal du straks kunne skrive kode af høj kvalitet. Og "høj kvalitet", og "skriv" og "straks". Lad mig forklare med en metafor.
At skrive kode af høj kvalitet er som at tale et fremmedsprog korrekt. Når du ikke kan et sprog, bruger du meget tid på at forsøge at formulere dine tanker i det.
Hvis du har brug for at sige noget akut, holder du bare på nogle ord, ofte ikke de rigtige, du glemmer alt om artikler, den korrekte ordstilling, for ikke at tale om verbum og dårlig udtale.
Hvis du har tid til at formulere et svar, skal du åbne en ordbog eller en onlineoversætter og bruge meget tid på at formulere dine tanker. Følelsen vil dog stadig være ubehagelig: du siger svaret, og du ved ikke, om det er korrekt eller ej. Det er det samme med koden - det ser ud til at være skrevet, det ser ud til at virke, men om det er af god kvalitet eller ej er et mysterium.
Det viser sig at være dobbelt spild af tid. Det tager tid at komme med et svar. Det tager også tid at formulere dette svar – og ikke så lidt.
Hvis evnen til at skrive kode af høj kvalitet er til stede, kan svaret formuleres med det samme, så snart det er modnet i hovedet, uden at bruge ekstra tid på oversættelse.
Evnen til at skrive kode af høj kvalitet hjælper, når du designer arkitektur. Du vil simpelthen ikke overveje forkerte, urealiserbare eller hånd-me-down muligheder i dit hoved.
For at opsummere: evnen til at skrive kode af høj kvalitet fremskynder problemløsning markant.
Men det er ikke alt. Takket være filtstøvlemanagerne er der én hake - vi har ikke en grund til at skrive kode af høj kvalitet. Lederen ser ikke på koden, klienten ser ikke på koden. Vi viser sjældent kode til hinanden, kun nogle gange, i nogle projekter, hvor der er en udpeget kode "checker" eller periodisk refactoring.
Det viser sig, at i de fleste tilfælde går den lorte kode til produktionen eller til kunden. En person, der har skrevet lortekode, danner en stabil neural forbindelse - det er ikke kun muligt at skrive lort kode, men det er også nødvendigt - det er accepteret, og de betaler endda for det.
Som et resultat har evnen til at skrive kode af høj kvalitet overhovedet ingen chance for at udvikle sig. Koden skrevet af en betinget medarbejder kontrolleres aldrig af nogen. Den eneste grund til, at han vil lære at programmere normalt, er intern motivation.
Men denne indre motivation er i konflikt med planer og krav til effektivitet og produktivitet. Denne modsigelse er tydeligvis ikke løst til fordel for kode af høj kvalitet, fordi folk ikke engang kritiserer folk for lort kode. Og for manglende opfyldelse af planen - alligevel.
Hvad skal jeg gøre? Jeg ser og foreslår to veje, der kan kombineres.
Den første er at vise din kode til nogen i virksomheden. Ikke reaktivt (når du bliver spurgt/tvunget), men proaktivt (uh, dude, se på min kode, tak). Det vigtigste her er ikke at poste sukkersødt snot, ikke at forsøge at sætte kritik af koden i en høflig form. Hvis koden er lort, siger vi det: koden er lort. Med forklaringer, selvfølgelig, og anbefalinger til, hvordan man kan gøre det bedre.
Men denne vej er også halvdårlig. Dens anvendelighed afhænger af det punkt, hvor kontakten fandt sted. Hvis arbejdet allerede er gået i produktion, og det viser sig, at koden er noget lort, nytter det ikke at lave det om. Mere præcist, årsagerne - metrikken vil også synke. Ledere vil skynde sig ind og knuse dig med effektivitetskrav. Og prøv ikke engang at forklare dem, at den lorte kode helt sikkert vil komme tilbage i form af fejl - det vil give bagslag på dig. Du kan kun forpligte dig til ikke at gøre dette igen.
Hvis arbejdet endnu ikke er leveret, eller lige er begyndt, så kan det have en ganske praktisk betydning at hælde lort på koden (eller dens projekt, idé) - personen vil gøre det normalt.
Den anden måde, den fedeste, er at lave open source-udvikling i ikke-arbejdstid. Hvad er målet: for en flok programmører, nemlig programmører, at se din kode og tale om den. Alle i virksomheden har ikke tid. Men programmører over hele verden har stadig ikke noget at lave, og hvis du skriver noget brugbart ud fra et applikationssynspunkt, vil de helt sikkert kigge ind.
Det vigtigste trick er efter min mening at skrive kode i ikke-arbejdstid, fordi modsætningen mellem kodens kvalitet og hastigheden på at levere resultatet ikke virker. Skriv din udvikling i mindst et år. Hverken deadlines, tekniske specifikationer, penge eller chef vil lægge pres på dig. Fuldstændig frihed og kreativitet.
Kun i fri kreativitet vil du forstå og mærke, hvad god kode er, se skønheden ved sprog og teknologi og mærke charmen ved forretningsopgaver. Nå, du vil lære at skrive kode af høj kvalitet.
Sandt nok vil dette kræve, at du bruger personlig tid. Ligesom enhver anden udvikling. Se det ikke som en omkostning, men som en investering – i dig selv.
Kilde: www.habr.com