Bedste svar
Interessant spørgsmål. For mig betyder udtrykket “håndværk” noget om den måde, den faktiske kode er skrevet på, snarere end om systemdesignet på højere niveau. Jeg vil sige, at veludformet kode gør følgende:
- Følger eksterne standarder
- Følger interne standarder
- Bruger gode mønstre
- Kan læses
Følger eksterne standarder. Hvis din gruppe har kodningsstandarder, skal du følge dem. Hvis du ikke ” ikke kan lide standarderne, følg dem stadig.
Følger interne standarder. Dette betyder, at koden skal være internt konsistent. Metoder, der gør lignende ting, skal anlægges på samme måde. Hvis en metode følger mønsteret:
if (success) {
doSomething();
} else {
handleError();
}
har ikke en anden metode, der begynder:
if (!success)
{
handleError();
Bruger gode mønstre. Med dette mener jeg kodemønstre snarere end designmønstre. Din kode skal bruge idiomer, der er passende for sproget. (Brug f.eks. scoped\_ptrs til hukommelsesadministration i C ++). Det bør undgå åbenlyse ineffektiviteter, såsom postincrementing C ++ iteratorer eller oprettelse objekter, der ikke bruges i hver kodesti.
Kan læses. Andre ingeniører læser din kode, og du læser igen det om mange år. Koden skal være så let at forstå som muligt. Alle de ovennævnte emner vedrører primært læsbarhed og minimering af uventede elementer i koden. Dine læsere skal være bekymrede over din kodes logik, ikke om at prøve at finde ud af, hvorfor en ikke-standardkonstruktion er blevet brugt. Hvis der er en ikke-standardkonstruktion, skal dine læsere vide, at den er der af en grund, ikke fordi du begik en fejl. (Tænk på din kode som et møbel. Overfladen skal være glat, og du skal ikke fange en splint, hvis du kører hånden over den. Enhver uregelmæssighed skal være der af en grund.)
Læsbarheden forbedres også ved fornuftig metode og variabelnavne og med passende kommentarer. Gå ikke overbord på at kommentere. Hvis det er indlysende, gider du ikke forklare det. Men har en slags oversigt, så læseren kender sammenhængen. (Det kan være indlysende, at koden omdanner input X til output Y, men det hjælper, hvis læseren har en idé om, hvorfor dette er nødvendigt.)
Svar
Managere er som småbørn. De vil have det, de vil have, og de vil have det NU ! Men i modsætning til småbørn har ledere halvt husket Harvard Business Review artikler, de citerer (uden at give referencer) for at retfærdiggøre deres krav. De har lært et sæt argumenter, der stumper nogle udviklere.
De siger, “Vi kan ikke tillade sig at gøre det rigtigt. Vi er nødt til at få det på markedet NU ! ”. Det er ikke sandt, ved du. Hvis de skynder deres spaghetti-kode i produktion, får de en chance for at pisse deres lanceringskunder nu, men koden kan ikke skaleres. Det betyder bare, at deres forretning kludrer sammen et stykke tid, før de kollapser.
De siger, “Vi frigiver en beta til vores lanceringskunder.” Hvad de mener er, at de vil have dig til at frigive perfekt, kundetilfreds kode før du ellers ville, bare fordi de blev enige om at kalde det et beta-testprogram. Det er magisk tænkning, som at tro på julemanden.
De siger, ”Jeg lover, at vi omskriver koden senere, hvis du frigiver din skøre, halvfærdige kode NU ! ” Lyder det ikke som “Jeg renser mit værelse senere far, hvis jeg kan se tv og spise sukkerholdige snacks NU ?” Problemet er, at senere aldrig kommer. Hver dag har lederen et valg om enten at tilføje nye funktioner eller at rydde op i det rodede rum, der er deres kodebase. Gæt, som de prioriterer. Og gæt hvad, rummet bliver mere rodet og rodet, så det tager længere og længere tid at rydde op. Det er sværere at arbejde i (at oprette nye funktioner) på grund af alt rodet.
Til sidst siger de: ”Vi har investeret for meget i denne kodebase. Det vil tage for lang tid at omskrive. Vi har brug for funktioner NU ! ” Det tager kun hver funktion to eller tre gange så lang tid at kode, på grund af det rodede rum, som softwareudviklere kalder teknisk gæld.
Gode udviklere, som tålmodige og kærlige forældre, skal stoppe vanvidet. De er nødt til at insistere, ”Undskyld kærlighed, men din HBR artikel siger: Indtægterne er bedre, alt andet lige . ”Du skal læse det mere omhyggeligt.Alle andre ting er ikke lige, hvis du opsamler teknisk gæld. Hvad med, hvis vi prioriterer funktioner, og måske er der noget, du kan sælge tidligere. ”
Du skal være voksen og bryde det til dem, at der ikke er sådan noget som julemanden, og ingen sådan en perfekt, kundetilfreds kode, indtil alle fejlene fjernes, og alle funktionerne er implementeret.
Du er nødt til at fortælle dem, “Vi har ikke råd til ikke for at bruge god praksis. Vi lever, eller vi dør, men vi er nødt til at gøre visse ting for at leve, som at skrive tests og dokumentation. Det er ikke en mulighed. “
Du er nødt til at smile og sige,” Vi vil aldrig omskrive denne kode. Jeg ved, du mener godt, men når det kommer til at rette koden eller tilføje nye funktioner, ved jeg hvad du vil sige. Det er hvad du altid siger. ”
Ved at være en fast forælder hjælper du din leder med at vokse op til at være den slags forretningsleder, du ønsker at arbejde for.