Beste svaret
Interessant spørsmål. For meg innebærer begrepet «håndverk» noe om måten den faktiske koden er skrevet på, snarere enn om systemnivå på høyere nivå. Jeg vil si at godt utformet kode gjør følgende:
- Følger eksterne standarder
- Følger interne standarder
- Bruker gode mønstre
- Kan leses
Følger eksterne standarder. Hvis gruppen din har kodestandarder, følg dem. Hvis du ikke gjør det » ikke lik standardene, følg dem fremdeles.
Følger interne standarder. Dette betyr at koden skal være internt konsistent. Metoder som gjør lignende ting bør legges ut på samme måte. Hvis en metode følger mønsteret:
if (success) {
doSomething();
} else {
handleError();
}
har ikke en annen metode som begynner:
if (!success)
{
handleError();
Bruker gode mønstre. Med dette mener jeg kodemønstre i stedet for designmønstre. Koden din skal bruke idiomer som er passende for språket. (Bruk for eksempel scoped\_ptrs for minnehåndtering i C ++.) Det bør unngå åpenbare ineffektiviteter, som for eksempel å øke C ++ iteratorer eller lage objekter som ikke brukes i hver kodebane.
Er lesbar. Andre ingeniører vil lese koden din, og du vil lese på nytt det på mange år. Koden skal være så lett å forstå som mulig. Alle elementene nevnt ovenfor er primært opptatt av lesbarhet, og med å minimere uventede elementer i koden. Leserne dine bør være opptatt av kodens logikk, ikke om å prøve å finne ut hvorfor en ikke-standard konstruksjon har blitt brukt. Hvis det er en ikke-standard konstruksjon, bør leserne vite at den er der av en grunn, ikke fordi du gjorde en feil. (Tenk på koden din som et møbel. Overflaten skal være glatt, og du bør ikke fange en splint hvis du kjører hånden over den. Eventuell uregelmessighet bør være der av en grunn.)
Lesbarheten forbedres også ved fornuftig metode og variabelnavn, og med passende kommentarer. Ikke gå overbord på å kommentere. Hvis det er åpenbart, gidder du ikke å forklare det. Men har en slags oversikt slik at leseren kjenner sammenhengen. (Det kan være åpenbart at koden transformerer inngang X til utgang Y, men det hjelper hvis leseren har noen ide om hvorfor dette er nødvendig.)
Svar
Ledere er som småbarn. De vil ha det de vil ha, og de vil ha det NÅ ! Men i motsetning til småbarn har ledere halvminnet Harvard Business Review artikler de siterer (uten å gi referanser) for å rettferdiggjøre deres krav. De har lært et sett med argumenter som stumper noen utviklere.
De sier: «Vi har ikke råd til å gjøre det riktig. Vi må få det på markedet NÅ ! ”. Det er ikke sant, vet du. Hvis de skynder spaghettikoden sin i produksjon, får de sjansen til å pisse av lanseringskundene nå, men koden kan ikke skaleres. Det betyr bare at virksomheten deres knuser sammen en stund før de kollapser.
De sier: «Vi vil gi en betaversjon til lanseringskundene våre.» Det de mener er at de vil at du skal gi ut perfekt, kundetilfreds kode tidligere enn du ellers ville gjort, bare fordi de sa ja til å kalle det et beta-testprogram. Det er magisk tenking, som å tro på julenissen.
De sier: “Jeg lover at vi vil skrive om koden senere hvis du slipper den kule, halvferdige koden din NÅ ! ” Høres ikke dette ut som «Jeg vil rengjøre rommet mitt senere, hvis jeg kan se på TV og spise sukkerholdige snacks NÅ ?» Problemet er at senere aldri kommer. Hver dag har lederen et valg å enten legge til nye funksjoner eller å rydde opp i det rotete rommet som er deres kodebase. Gjett hvilket de prioriterer. Og gjett hva, rommet blir rotere og rotere, slik at det vil ta lengre og lengre tid å rydde opp. Det er vanskeligere å jobbe med (å lage nye funksjoner) på grunn av alt rotet også.
Til slutt sier de: “Vi har investert for mye i denne kodebasen. Det vil ta for lang tid å skrive om. Vi trenger funksjoner NÅ ! ” Bare hver funksjon tar to eller tre ganger så lang tid å kode, på grunn av det rotete rommet som programvareutviklere kaller teknisk gjeld.
Gode utviklere, som tålmodige og kjærlige foreldre, må stoppe galskapen. De må fast insistere, «Beklager kjærlighet, men HBR artikkelen sier: Inntektene er bedre, alt annet er likt . Du må lese det mer nøye.Alle andre ting er ikke like hvis du hoper opp teknisk gjeld. Hva med om vi prioriterer funksjoner, og kanskje det vil være noe du kan selge tidligere. ”
Du må være voksen og bryte det til dem at det ikke er noe som heter julenissen, og nei slik som perfekt, kundetiltalende kode til alle feilene er fjernet og alle funksjonene er implementert.
Du må si til dem: “Vi har ikke råd til ikke for å bruke god praksis. Vi lever, eller vi dør, men vi må gjøre visse ting for å leve, som å skrive tester og dokumentasjon. Det er ikke et alternativ. «
Du må smile og si:» Vi vil aldri skrive om denne koden. Jeg vet at du mener godt, men når det kommer til å fikse koden eller legge til nye funksjoner, vet jeg hva du vil si. Det er det du alltid sier. ”
Ved å være en fast forelder, hjelper du lederen din med å vokse opp til å være den slags forretningsleder du ønsker å jobbe for.