Et av de mest idiotiske yrkene er ledere som administrerer programmerere. Ikke alle, men de som ikke var programmerere selv. De som tror at det er mulig å «øke» effektiviteten (eller øke «effektiviteten»?) ved hjelp av metoder fra bøker. Uten engang å bry seg om å lese de samme bøkene, er videoen en sigøyner.
De som aldri har skrevet kode. De som Hollywood-filmer om programmerere er laget for – vel, de der de ser e-post ved hjelp av kommandolinjen. De som ikke er interessert i annet enn indikatorer, frister og egen lønn.
De som er flertallet.
Men de er idioter av en annen grunn. De vil ha effektivitet, eller i det minste effektivitet (kom igjen, leder, Google hva forskjellen er), uten å forstå verken det ene eller det andre. Uten generelt å forstå essensen, prosessen med å oppnå resultatet, tapene som oppstår i denne prosessen, kostnadene ved utvikling. Kort sagt, å jobbe med en programmerer som om han var en svart boks.
De kom løpende inn i ledelsen av programmerere av nøyaktig én grunn: det er hype, penger, markedet og en haug med de samme idiotene. Det er et sted å gå seg vill.
Hvis det var hype i mekanisk monteringsproduksjon, ville vi kjørt dit. Stasjonsvogner suger. Jeg ville ikke bli overrasket over at fyren som selger juletrær i nabolaget vårt i desember er en IT-sjef på ferie.
Kort sagt, hvis mulig, skyt disse gutta i nakken. Ikke bekymre deg, de vil finne en jobb. Ingen av dem vil noen gang gjøre noe anstendig før de blir programmerer selv. Fordi han ikke forstår essensen, mekanismen, logikken i prosessen han kontrollerer.
Ok, nok om ledere. Nå til poenget, for programmerere. Hvordan øke utviklingseffektiviteten ved å lære å skrive kode av høy kvalitet.
For å øke effektiviteten må du løse problemer raskere uten å miste kvalitet. For å løse problemer raskere, må du umiddelbart kunne skrive kode av høy kvalitet. Og "høy kvalitet", og "skriv" og "umiddelbart". La meg forklare med en metafor.
Å skrive kode av høy kvalitet er som å snakke et fremmedspråk riktig. Når du ikke kan et språk, bruker du mye tid på å prøve å formulere tankene dine i det.
Hvis du trenger å si noe akutt, holder du bare på noen ord, ofte ikke de riktige, du glemmer artikler, riktig ordrekkefølge, for ikke å snakke om verbtid og dårlig uttale.
Hvis du har tid til å formulere et svar, må du åpne en ordbok eller en nettoversetter og bruke mye tid på å formulere tankene dine. Følelsen vil imidlertid fortsatt være ubehagelig: du sier svaret, og du vet ikke om det er riktig eller ikke. Det er det samme med koden - det ser ut til å ha blitt skrevet, det ser ut til å fungere, men om det er av god kvalitet eller ikke er et mysterium.
Det viser seg å være dobbelt bortkastet tid. Det tar tid å komme med et svar. Det tar også tid å formulere dette svaret – og ikke så lite.
Hvis ferdigheten til å skrive kode av høy kvalitet er til stede, kan svaret formuleres umiddelbart, så snart det har modnet i hodet, uten å bruke ekstra tid på oversettelse.
Ferdigheten til å skrive kode av høy kvalitet hjelper når du designer arkitektur. Du vil rett og slett ikke vurdere ukorrekte, urealiserbare eller hånd-me-down-alternativer i hodet ditt.
For å oppsummere: ferdigheten til å skrive kode av høy kvalitet øker problemløsningen betydelig.
Men det er ikke alt. Takket være filtstøvlenes ledere er det en hake - vi har ingen grunn til å skrive kode av høy kvalitet. Lederen ser ikke på koden, klienten ser ikke på koden. Vi viser sjelden kode til hverandre, bare noen ganger, i noen prosjekter der det er en utpekt kode "sjekker" eller periodisk refaktorering.
Det viser seg at i de fleste tilfeller går den skitne koden til produksjon eller til klienten. En person som har skrevet elendig kode danner en stabil nevral forbindelse - det er ikke bare mulig å skrive elendig kode, men det er også nødvendig - det er akseptert, og de betaler til og med for det.
Som et resultat har ferdighetene til å skrive kode av høy kvalitet ingen sjanse til å utvikle seg i det hele tatt. Koden skrevet av en betinget ansatt blir aldri sjekket av noen. Den eneste grunnen til at han vil lære å programmere normalt er indre motivasjon.
Men denne indre motivasjonen er i konflikt med planer og krav til effektivitet og produktivitet. Denne motsetningen er tydeligvis ikke løst til fordel for kode av høy kvalitet, fordi folk ikke engang kritiserer folk for dårlig kode. Og for manglende oppfyllelse av planen - likevel.
Hva burde jeg gjøre? Jeg ser og foreslår to veier som kan kombineres.
Den første er å vise koden din til noen i selskapet. Ikke reaktivt (når du blir spurt/tvunget), men proaktivt (uh, dude, se på koden min, takk). Hovedsaken her er å ikke legge ut sukkersøtt snørr, ikke prøve å sette kritikk av koden i en høflig form. Hvis koden er dritt, sier vi det: koden er dritt. Med forklaringer, selvfølgelig, og anbefalinger om hvordan du kan gjøre det bedre.
Men denne veien er også så som så. Dens anvendelighet avhenger av punktet der kontakten skjedde. Hvis arbeidet allerede har gått i produksjon og det viser seg at koden er dritt, er det ingen vits i å gjøre den på nytt. Mer presist, årsakene - beregningene vil også synke. Ledere vil skynde seg inn og knuse deg med effektivitetskrav. Og ikke engang prøv å forklare dem at den elendige koden definitivt vil komme tilbake i form av feil - den vil slå tilbake på deg. Du kan bare forplikte deg til ikke å gjøre dette igjen.
Hvis arbeidet ennå ikke er levert, eller nettopp har begynt, kan det å helle dritt på koden (eller dens prosjekt, idé) ha en ganske praktisk betydning - personen vil gjøre det normalt.
Den andre måten, den kuleste, er å utvikle åpen kildekode utenom arbeidstid. Hva er målet: for en haug med programmerere, nemlig programmerere, å se koden din og snakke om den. Alle i selskapet har ikke tid. Men programmerere over hele verden har fortsatt ingenting å gjøre, og hvis du skriver noe nyttig fra et applikasjonssynspunkt, vil de definitivt se inn.
Hovedtrikset, etter min mening, er å skrive kode i ikke-arbeidstid, fordi motsetningen mellom kvaliteten på koden og hastigheten på å levere resultatet vil ikke fungere. Skriv utviklingen din i minst ett år. Verken tidsfrister, tekniske spesifikasjoner, penger eller sjef vil legge press på deg. Fullstendig frihet og kreativitet.
Bare i fri kreativitet vil du forstå og føle hva god kode er, se skjønnheten i språk og teknologi, og føle sjarmen med forretningsoppgaver. Vel, du vil lære å skrive kode av høy kvalitet.
Riktignok vil dette kreve at du bruker personlig tid. Akkurat som enhver annen utvikling. Se på det ikke som en kostnad, men som en investering – i deg selv.
Kilde: www.habr.com