Efter att ha läst “Clean Code” lärde jag mig detta

Jag har läst klart koden av farbror Bob. När jag gillar att skriva ner allt jag läser, tänkte jag att det skulle vara en bra idé att sammanfatta boken och skapa en praktisk lekbok.

Självklart är denna lista inte fullständig. Det kommer förmodligen att utvecklas och förändras på många sätt, när jag upplever och upptäcker fler kodningsstilar, scheman och synpunkter.

Eftersom en ren kod bör läggas ut kommer denna artikel att beskrivas på samma sätt. Först kommer jag att täcka makroprinciperna – de övergripande idéerna och begreppen ren kod.

Ren metod för kodning

Utvecklare skriver kod för sitt yrke, de läser också en hel del. Faktum är att de flesta utvecklare läser mer än den faktiska kodningen.

Hur många gånger har du läst koden du just skrivit? Uppenbarligen är förhållandet för läsning än för verklig kodning.

Om det mesta av vår tid går åt till att förstå och läsa kod, är det bättre att se till att när vi faktiskt kodar, kommer det att vara otvetydigt för alla våra kamrater.

Eftersom du förmodligen kommer att bli nästa person att läsa koden du skriver, se till att du kommer att förstå den även om två månader. Jag är säker på att nästan varje programmerare (åtminstone jag) har skrivit kod klockan 03.00 bara för att vakna nästa dag och spendera timmar på att försöka förstå vad som händer.

Att se till att din kod är tydlig och ren kommer att minimera WTF -ögonblicken, förbättra din produktivitet och ha långsiktiga resultat. Gör dig själv en tjänst och börja skriva ren kod.

Det finns fler parametrar att koda än “fungerar” kontra “fungerar inte”

Koden ska inte mätas enbart på “fungerar” eller “fungerar inte”. Naturligtvis är kod som inte fungerar inte bra – för den fungerar inte.

Men kod som fungerar är inte nödvändigtvis bra, och det är en mycket viktig skillnad att göra. När vår kod visar sig fungera är vårt jobb som utvecklare inte klart.

En professionell utvecklare ser till att efter att koden klarat alla tester är den också tydlig, ren och underhållbar. De faktiska principerna för hur man skriver ren kod kommer att följa, men för närvarande får vi inte bara bedöma koden utifrån dess funktionsförmåga.

Det finns fler parametrar och vägledande principer för vad som är en välskriven kodbit.

Bättre klar än smart

Som mjukvaruutvecklare ägnar vi oss åt problemlösning, kreativitet och intensivt tänkande. Många gånger, när vi stöter på komplexa problem, kan vår kod visa sig vara “smart”- som i att göra mycket smarta saker som bara den som har skrivit koden kan förstå vad det är som händer.

Det är ett oönskat resultat, även när problemet är svårt att lösa.

Sann behärskning och professionalism är att lösa ett komplext problem och visa upp lösningen rent och tydligt så att andra människor kommer att kunna granska koden och vara delaktig i den. Det är inte för att vi behöver vara trevliga mot våra kollegor och dela med sig av det roliga (även om det också är en bra anledning), snarare än om du är den enda som förstår koden kommer det att skada dig på lång sikt.

Dina kollegor kommer inte bara att ha svårt att återskapa koden, det kommer också att begränsa projektet och göra det långsammare – och du kommer att vara knuten till en kod för alltid tills du dör eller lämnar företaget.
Vi måste se till att lösningen verkar tydlig och enkel för alla som läser den koden efter att vi har löst ett problem.

Förväntan och tillit är avgörande

När någon läser din kod finns det en process för att bygga upp förtroende mellan dig och läsaren. Tillit förmedlas i princip till förtroende. Läsaren har en viss tillit till koden du har skrivit, och när förtroendet är högt kan projektet gå snabbare.

Jag hoppas att det är klart nu att läsaren också är ditt framtida jag. Om du inte litar på din egen kod, lycka till.

Så hur kan vi bygga upp förtroende och förtroende hos läsaren? Genom att låta dem förutse korrekt vad som kommer att hända. När läsaren förstår koden, vet vad koden ska göra och korrekt förutser vad som kommer att hända, byggs förtroende upp mellan sidorna.

Förhindra överraskningar, oklarhet och tvetydig kod som kan förvirra läsaren. Om en funktion eller en klass förväntas utföra en viss handling, men läsaren blir förvånad och andra handlingar görs – förtroendet skakas och läsaren kan inte lita på programmeraren längre, hur skulle de kunna göra det? De hade fel på denna kod, och nu kommer de att vara i ett konstant gissnings läge under hela recensionen.

Ren kod sker inte direkt, av sig själv

Nu när vi har lagt fram varför ren kod är avgörande för vår framgång som utvecklare, står vi inför den ödesdigra frågan:

Hur skriver jag ren kod?

Tja, det händer säkert inte av sig själv. det kräver övning, kontinuerliga iterationer och refactoring, och ständigt följa principerna för ren kod. Farbror Bob nämner tydligt att även han inte skriver ren kod första gången. varje kod kod undersöks efter att den har skrivits och refaktorerats för att följa principerna för ren kod.

Tidlösa principer

Separata bekymmer

Varje avsnitt i koden bör behandla ett visst problem med programvaran. Att skriva funktioner eller klasser som innebär distinkta problem är inte ett exempel på ren kod. Håll istället affärslogiken åtskild. Oavsett om vi pratar i termer av moduler, klasser, funktioner – var och en i sin egen abstraktionsnivå.

Ändå är principen enkel: Vad är logiken jag skriver nu? Vad är det största problemet här? Har jag andra problem som genomförs? Om du gör det, separera dem.

Koden är som en artikel

En artikel, eller en blogg, har en tydlig struktur. Huvudämnet är högst upp, och när vi fortsätter med artikeln kan vi märka att huvudämnet är uppdelat i underdelar, och inom dem har vi mer information om varje del.

Koden bör följa samma princip.

I början kommer vi att ha det största bekymret som koden handlar om. När vi utvecklas kommer funktionen och klasserna att innehålla mer detaljer om genomförandet och hålla en tydlig separering av oro-precis som varje blogg har en underrubrik och ett stycke som är nära relaterat till det.

Varje kod bör delas in i klasser och funktioner som behandlar ett specifikt problem, och när vi fortsätter inom dem hanterar de bara det problemet

Scoutregeln

När jag var på scouterna var jag instruktör för barn med särskilda behov. Vår vägledande princip när vi åkte på utflykter var “lämna platsen renare än du hittade den”.

Uppenbarligen känner farbror Bob i sin bok ungefär samma sak om kod – Lämna alltid koden bättre än du hittade den. Som diskuterats tidigare är ren kod en process. Den består av kontinuerlig förbättring och utveckling, av dig och av andra i organisationen.

Lämna därför koden bättre än du hittade den. Dåliga variabelnamn, värdelösa kommentarer, kommenterad kod – ju längre den stannar desto luktigare blir den. Var proaktiv. Var en scoutpojke.

Ren, återanvändbar och underhållbar

Se alltid till att din kod följer dessa riktlinjer. Genom att se till att det gör det, kryssar du av de flesta av bokens principer. Ren kod är kod som har en bra struktur, är tydlig, väl namngiven och inte innehåller överraskningar.

Återanvändbar kod tvingar dig att separera problem, behålla rätt abstraktionsnivå och hindrar dig från att skriva kod som är logiskt beroende av andra avsnitt (mer om det senare).

Underhållbar kod tillåter andra att bidra och förstå vad som händer. Det tar hänsyn till att programvara omvandlas med tiden. Förutse därför ändringar och se till att koden blir lätt att återskapa om ändringar sker.

Aldrig duplicera

Dubblering innebär att koden inte är ren. Följ DRY -principen – upprepa inte dig själv. Dubbleringskrik för en funktion, klass, komponent- vad som helst! duplicera bara inte!

När du befinner dig med minsta ctrl+c och ctrl+v -sekvens, fråga dig själv intuitivt om det finns ett bättre alternativ. För det mesta blir svaret ett definitivt JA.

Undvik logiskt beroende

Logiskt beroende innebär att en kodbit förlitar sig på en separat kodbit för att innehålla viss affärslogik, förutsatt att koden inte ändras och därför är implementeringen bra.

När vi skriver kod måste vi se till att koden är “på egen hand” – att vi har rätt abstraktionsnivå, att koden inte känner till information som den inte ska veta (baserat på dess nivå av abstraktion och oro) och att om koden omstruktureras kommer vi inte att få ovanligt många biverkningar även i andra funktioner och klasser.

Pages: 1 2 3 4 5


Posted

in

,

by

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *