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

Allmänna begrepp för ren kod

Den bästa kommentaren är kommentaren du inte skrev

Kommentarer i kod, exklusive tekniska aspekter, ska mildras så mycket som möjligt. De är svåra att underhålla, de brukar försöka täcka upp till kod som inte är tillräckligt ren.

Om du känner att du behöver skriva en kommentar som förklarar vad koden gör, bör det lyfta en röd flagga och du bör granska din kod och se till att den är tillräckligt ren.

Vi syftar inte på kommentarer som ingår i bibliotekets dokumentation eller tekniska kommentarer om licensiering.

Kommentarer bör mildras. Den ledande principen är att om du behöver förklara vad koden gör, är koden inte tillräckligt tydlig. Koden bör förklara sig själv. Det bör vara självförklarande för andra kamrater att granska.

Förstå algoritmen

Att förstå algoritmen är ett avgörande steg för att skriva ren kod.

Utöver de uppenbara anledningarna till att vi behöver förstå algoritmen kan man bara skriva ren kod om han förstår den på riktigt.

Om vi ​​lägger tid på att lära oss algoritmen och se till att vi känner till dess krångel, kommer vi att kunna dekonstruera den i mindre delar.

Därifrån är vägen till att skriva ren kod ganska enkel
vår förmåga att skriva ren kod härrör från vår förståelse av algoritmen och väljer de exakta punkterna för att dekonstruera den till mindre delar

Akta dig för abstraktionsnivåer

En abstraktionsnivå är ett viktigt koncept att tänka på när man planerar och skriver kod. Medan vi skriver en funktion överväger vi var den står i lösningens stora schema.

Är det en funktion på hög nivå som är nära besläktad med algoritmen? Eller är det en funktion som är ansvarig för ett nyttighetssyfte (som att analysera en kommandorad, kontrollera villkor, utföra vissa beräkningar)?

Abstraktionsnivåprincipen är ett annat sätt att se till att vi håller alla våra funktioner och klasser på plats och att våra funktioner bara gör en sak. Om en funktion blandar abstraktionsnivåer gör den definitivt mer än en sak.

Att tänka i abstraktion är ett verktyg för att hjälpa oss att organisera strukturerna på funktionerna bättre och planera hur hela pusslet sätts ihop.

För att bli praktisk kommer vi alltid att börja med de högre nivåerna som ligger på den högsta abstraktionsnivån. Varje funktion ska bara sjunka en nivå under medan den kallar den andra funktionen.

Som vi redan har täckt kommer de detaljerade detaljerna i algoritmen och den specifika implementeringen att avslöjas längre ner i källkoden.

Den ledande frågan är vad jag bryr mig om i denna logik? Naturligtvis bryr vi oss om varje rad. Men vad är den absolut viktigaste delen av algoritmen, där huvudlogiken finns? Det är den högsta abstraktionsnivån.

Orkestrering av hela logiken. Tvättkontroll, felhantering, analys, beräkningar – de är på en annan abstraktionsnivå. De bör extraheras till olika funktioner, var och en har sin egen abstraktionsnivå.

Tänk på följande kod:

//Mongoose call to create a product
async function createProduct(productToSave) {
  try {
    const product = new Product(productToSave)
    return await product.save()
  } catch (e) {
    _handleError('failed to create product in db', e)
  }
}

Märkte du _handleError -funktionen? Förutom att peka exakt vad som var felet, har funktionen createProduct ingen aning om hur felet hanteras. Det går bara längs med felet och låter en annan funktion på en lägre abstraktionsnivå.

Varför är det så? För det är inte dess ansvar. Funktionen får en produkt och returnerar en sparad produkt från DB. Fel? bra. Inte dess ansvar. Den aktiverar _handleError -funktionen för att göra exakt vad titeln avslutar: Att hantera fel.

function _handleError(msg, e = 'initiated') {    
      logger.error(msg, e)    throw Error(msg, e)
}

Har funktionen ovan någon aning om vad logen gör med felet? Inte alls.

Som vi förmodligen har förstått är det inte sitt jobb att logga felet. Dess uppgift är att hantera felet – ring de relevanta funktionerna på nästa lägre abstraktionsnivå och vidarebefordra informationen

Slutord: Var konsekvent

Avslutningsvis tror jag att detta är ett recept på ren kod och att vara en bra programmerare. Alla har sin egen stil, unika synvinkel och ett annat sätt att lösa problem.

Att vara konsekvent med alla principer som nämns i denna artikel är därför nyckeln till att kunna skriva underhållbar, återanvändbar, tydlig och ren kod.

Pages: 1 2 3 4 5


Posted

in

,

by

Comments

Leave a Reply

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