Kode kalligraf VS kode kyllingeskrab

I løbet af de sidste 17 år har jeg arbejdet på over 90 projekter med mange hold. Men det var først, da jeg stødte på Gits blamefunktion, at jeg lærte om hver koders "håndskrift". Denne enkle nysgerrighed blev hurtigt en vane. Hver gang jeg så ny kode, forsøgte jeg at gætte, hvem der skrev den. Så bekræfter jeg mit gæt med en git blame.

(Forresten, hvis du ikke er bekendt med git endnu, er det en populær måde for udviklere at samarbejde om kode, og dens "skyld" -funktion viser dig, hvem der har skrevet en given linjekildekode.)

Efter et par år begyndte jeg at se mønstre, ligesom en håndskriftekspert måske kunne opdage en sociopat fra den måde, de tegner deres W'er på. Kodehåndskrift afslører meget om programmøren, der skrev den.

Du kan lære næsten alt fra en programmerings kodehåndskrift: hvor meget erfaring de har, hvor meget de holder af deres kodes læsbarhed (og i forlængelse, hvor meget de holder af deres holdkammerater).

Kodetaler. Dårlig kode skriger! Så er koden, du læser kode kalligrafi, eller koder den kyllingeskrab?

En hurtig ansvarsfraskrivelse: Det, du er ved at læse, er udelukkende baseret på min subjektive intuition. Så vidt jeg ved, har der ikke været nogen peer-reviewed akademiske studier. Mine færdigheder til analyse af kodehåndskrift har tjent mig godt tidligere og kan også hjælpe dig, men - som med alt, hvad du læser på internettet - kan din kilometertal variere.

Indsigt nr. 1: Oppustet kode = kamp

Normalt når jeg opdager kode, der er blevet oppustet, og langt større end den skal, viser det en programmør, der kæmpede for at afslutte en opgave, der var uden for deres evner. De havde enten ikke viden eller tid til at afslutte jobbet ordentligt.

I det virkelige liv har folk, der gør mindre, en tendens til at tale mere. Det er det samme i kode land: de, der ikke kan udføre jobbet elegant, har en tendens til at skrive en masse kode.

Desværre fejrer bugs på kode, og jo flere kodebestemmelser, jo større er habitatet for bugs.

”Jeg hader kode, og jeg vil have så lidt af det som muligt i vores produkt” - Jack Diederich

Indsigt nr. 2: død kode = sløvhed

Har du nogensinde set store blokke af kommenteret kode, der er forpligtet til repoen? Eller endnu værre: kode, der ikke gør noget særligt, men er der af historiske årsager?

Interessant nok har dette en direkte sammenhæng med rodet på skrivebordet til programmøren, der skrev det. Nogensinde set forældede kommentarer eller tests? Ja, du fandt en skødesløs programmør.

3. Kompleks kode = dumhed eller grådighed

Jeg elsker dette citat fra Schumacher:

”Enhver intelligent fjols kan gøre tingene større, mere komplekse og mere voldelige. Det kræver et strejf af geni - og meget mod til at bevæge sig i den modsatte retning. ” - Fritz Schumacher

Hvis du fandt kode, der er vanskelig at følge eller forstå, kan du være sikker på at den blev skrevet enten af ​​en person, der ikke har en anelse om, hvad de laver, eller af en person, der søger jobsikkerhed ved at tage "ejerskab" af den del af koden.

Indsigt # 4: Kommentarer = en holdspiller (medmindre ...)

Alle sprog på højt niveau tillader skrivning af kode, der er læselig nok til, at du ikke skal bruge kommentarer. Men nogle gange er kompleksitet uundgåelig på grund af manglende viden, tid eller elegante rammer.

Jeg elsker det virkelig, når programmører sætter et link til API-reference eller et relevant Stack Overflow-spørgsmål, når de er klar over, at deres jævnaldrende (eller deres fremtidige selv) vil stille spørgsmålstegn ved en bestemt linje med kode.

Når det er sagt, viser overforbrug af kommentarer en mangel på selvtillid (eller som jeg nævnte tidligere, forsøger at forklare "oppustet kode").

Indsigt nr. 5: Navne = kommunikationsevne

Variabelnavne, funktionsnavne, parameternavne, klassenavne. Dette er det grundlæggende niveau for kommunikation til kodeholdere.

Hvis du støder på enkeltnavne (undtagen i, hvilket er standard i forsløjfer), har du fundet en programmør med manglende kommunikationsevner eller empati for andre.

Medmindre det er et midlertidigt projekt, der ikke vil blive vist til nogen anden eller vedligeholdt, resulterer hvert sekund i at vælge et passende navn i god karma.

Og hvis en enheds funktionalitet ændres, er det vigtigt at omlægge dets navn i overensstemmelse hermed.

Nogle programmører hævder, at navne ikke er vigtige, da maskinerne ikke er ligeglade. Nå, medmindre du skriver kode bogstaveligt i nuller og ener, skriver du også kode til mennesker!

Indsigt nr. 6: Dårlig læsbarhed = manglende flydende

Nogle gange er programmører flydende på et sprog, men de prøver at vride og bøje et andet sprog for at opføre sig som deres yndlingssprog.

JavaScript er et af de dårlige målsprog.

De fleste backend-programmører har den luksus at vælge deres ”modersmål”. Og mange er modige nok til at hacke sammen et par linjer med front-end-kode. Men da browserens land for det meste er JavaScript (som er et fleksibelt sprog), prøver de at efterligne hvilke mønstre, der nogensinde er kendt for dem fra deres "modersmål".

Dette er godt og godt, indtil en egentlig JavaScript-programmør ser koden og trækker deres hår ud!

Indsigt nr. 7: Hacks = lav personlighed eller manglende disciplin

Har du nogensinde brugt masser af tid på at rydde op i en kodebase for kun at være vidne til din jævnaldrende hælde benzin over hele din smukke kode ved at bruge den som en platform til hurtige og beskidte rettelser?

Tillykke: du mødte en hacker!

Hackere er gode til at lave hurtige rettelser uden at gider at forstå arkitekturen holistisk (normalt ved at fusses med en debugger eller gennem prøving og fejl).

Så hvad er fangsten? De løser et problem og opretter 10 andre.

Konsulenter har en tendens til at vise denne adfærd (da deres tid er dyr, og de ikke vil leve med konsekvenserne af deres ændringer). Desuden kan de få betalt for at løse disse 10 andre problemer og så jobsikkerhed ved at lave 100 nye.

Ikke desto mindre har jeg været vidne til interne programmerere, der får selv de sjoveste konsulenter til at ligne rockstjerner. Har du nogensinde estimeret, at et emne vil tage 8 timer, men en eller anden produktchef reducerer dit estimat til kun 1 time? Det er normalt når hackerne er født.

Når det er sagt, har du nogle gange brug for hurtig levering (som i prototypefasen i en opstart for at validere ideen), og det accepteres at skære hjørner på grund af begrænsede ressourcer. Ingen bryr sig om en smuk kode, der ikke løser noget problem. Men der er stadig en forskel mellem at skære med en saks eller hugge med en machete!

Indsigt # 8: inkonsekvens = stolthed og fanatisme

Når du er i Rom, skal du gøre som romerne. - et ordsprog

Der er så mange kodningskonventioner. Det betyder ikke rigtig, hvilken der vælges. Men når dit team vælger nogle konventioner, er det afgørende, at de holder fast ved dem.

Hvis bidragsydere ignorerer nogle eller alle konventioner, hacker de enten væk eller er for stolte til at ændre deres stil til at matche din kodebase.

Værst af alt er, når de skubber til deres egne konventioner i stedet. Det er ren fanatisme. Og du kan være sikker på, at programmøren også er snæversynet.

Indsigt # 9 WET-kode = dårlig hukommelse

Det modsatte af Dry ("Gentag ikke dig selv") er WET ("Vi nyder at skrive" eller "Skriv alt to gange").

Nå reproduceres bugs gennem en rodet proces kaldet "kopi" og "indsæt".

Der er overraskende mange typer WET-kode. For eksempel:

  1. En funktion eller klasse, der er skrevet to gange, kun med mindre forskelle
  2. En variabel, der indeholder værdien af ​​en anden variabel
  3. Et sæt gentagne instruktioner, der kunne findes i en funktion

Dette adskiller sig fra oppustet kode, idet WET-kode gentages bogstaveligt talt i stedet for blot at være kompleks eller snoet.

Normalt er gentagen kode et tegn på, at en programmør ikke kan huske (eller værre, ikke har set) den anden lignende kode. En af de vigtigste opgaver for den menneskelige hjerne er at opdage mønstre. Når en programmør ikke er i stand til at få øje på lignende kode, er det et tegn på manglende erfaring eller uopmærksomhed for detaljer.

Indsigt # 10. Midlertidige løsninger = manglende disciplin

Nogle gange vil udviklere indsprøjte en hurtig og beskidt løsning som en midlertidig løsning i håb om, at de en dag kommer rundt for at omlægge den. Dette sker normalt på grund af en tæt deadline eller manglende viden. Men som vi alle ved, er midlertidige løsninger der for at blive.

Midlertidige løsninger indikerer en pragmatisk ingeniør, der mangler enhver smag eller stolthed i deres arbejde. De kan også være et tegn på lav selvtillid, fordi de ikke vil skuffe en anden (chef, kunde osv.).

Den eneste gang, en midlertidig løsning er acceptabel, er et læringsprojekt eller prototyping (proof of concept). Og selv i disse tilfælde er det bedst at omlægge det, så snart du ved, hvordan du gør det på den rigtige måde.

Indsigt nr. 11: Masser af afhængigheder = skødesløshed for projektets fremtid

Afhængigheder skal holdes ajour. Når et projekt har for mange afhængigheder, er det et tegn på sløvhed.

Det er svært at sige, hvad der er "for meget", men tommelfingerreglen er: hvis projektet let kan overleve uden afhængighed, er det overflødigt.

En anden foranstaltning er, at hvis der ikke er noget nødvendigt krav til det underliggende problem, som afhængigheden løser, er det sandsynligvis unødvendigt.

Der er tre motiver for unødvendige afhængigheder:

Årsag nr. 1: Udvikleren er for ivrig efter at lære nye ting.

Ved at importere nye afhængigheder får de chancen for at lære den i et rigtigt projekt.

Nysgerrighed er god, men der bør være andre platforme til læring, som sideprojekter, kortsigtede opgaver eller hackathons.

Du vil ikke miste en god udvikler, fordi de tror, ​​at de ikke kan vokse på deres job, men du vil heller ikke have, at de skal behandle dit produkt som deres kæledyrsprojekt.

Årsag nr. 2: Det udføres af en alt for ambitiøs juniorudvikler.

Begynderne på ethvert felt har tendens til at blive overvældet af alle de nye buzzwords, og af frustration eller uvidenhed (eller anbefaling fra en "pro") kan de beslutte at "hoppe i puljen" og lære alt på én gang. Lad dem ikke. Vælg din teknologi.

Årsag nr. 3: Udvikleren har bagage fra et andet job (eller et sideprojekt)

De vil have en kant over deres jævnaldrende ved at bringe noget ind, som kun de ved meget godt.

Desværre er der ingen nem løsning på dette, men bløde færdigheder: Holdet skal sætte spørgsmålstegn ved valget af enhver afhængighed, og hvis der er en ordentlig kode-gennemgang og fusioneringsproces på plads, gør det det svært at snige sig frygtelig kode ind uden at nogen bemærker det.

Nogle gange kan den pågældende cowboykoder foretage en massiv refactoring og derefter sætte holdet i stand til at acceptere hele forandringen, fordi det allerede er gjort. Nå, ikke! Bed dem om at opdele deres trækningsanmodning i mindre dele og vær skeptiske over for at bringe nye afhængigheder. Ja, det er mere arbejde, men det sparer meget mere tid og energi på lang sigt.

Gode ​​udviklere er interesserede i fremtiden for deres projekt, fordi de brugte deres mest begrænsede og dyrebare ressource på at skabe det: deres tid!

Forresten kan mange afhængigheder og trendy buzzwords også være et tegn på, at udvikleren er ved at opbygge et CV og allerede klar til deres næste job.

Kode kalligrafi

Nu hvor vi har diskuteret kode kyllingeskrabning, lad os tale om bagsiden: kode, der er en absolut fornøjelse at læse.

Nogle siger endda "kode er poesi."

Kildekoden til jQuery eller lodash er gode eksempler, men stort set alle populære biblioteker på Github, som mange bidragydere i sidste ende vil konvergere til skønhed. Dette, mine venner, er vidunderlig kodekalligrafi .

I det væsentlige er god kode:

  1. Let at læse, følge og debug
  2. Fleksibel, konfigurerbar og udvidelig
  3. Smart med ressourceforbrug
  4. Høj ydeevne

Bemærk, at nogle projekter kræver en anden rækkefølge. For eksempel er Linux-kildekoden muligvis ikke meget let at læse, fordi ydeevne er vigtigere for et operativsystem. Eller en ydmyg integreret IoT-applikation kan ofre konfiguration til fordel for ressourceoptimering.

Under alle omstændigheder er der meget mere, du kan finde ud af om dine jævnaldrende bare ved at analysere deres kode. Kode taler højere end ord! Så næste gang du læser en kode, skal du prøve git blamekommandoen og begynde at genkende kodehåndskrift.

⚡ ️ Kan du lide det, du læser? Følg mig for at få besked, når jeg skriver noget nyt.

Du vil måske også tjekke, hvorfor programmering er det bedste job nogensinde.