| Identifierare & Förklaring | Reflektion |
|---|---|
f Är TS-Fuse objektet som håller alla funktioner för att skapa upp scheman. |
Don't Add Gratuitous Context Medans f i sig inte har vad jag skulle kalla för mycket kontext så är den ett extra kontext för alla scheman som kanske hade kunnat importerats för sig. Add Meaningful Context Jag skulle säga att f är väldigt otydligt om du inte vet vad biblioteket redan gör. Det är valt för jag namngav biblioteket ts-fuse (TypeScript Brytare) och f kom få från fuse, men för tydlighetens skull borde man nog kallat den något närmare TypeValidationSchemas. |
f.String() Är funktionen som skapar ett String schema. ( f.Boolean() & f.Number() har samma problem) |
Use Intention-Revealing Names Medans f.String() är väldigt tydligt i att det handlar om en sträng så är det inte jätte tydligt att det är en funktion som skapar upp ett validerings schema. En möjlig lösning hade kunnat vara att låta användare skapa schemat såhär: const schema = new StringValidationSchema(). Det skulle vara väldigt långt, men det skulle vara tydligt. Avoid Disinformation Det finns en risk att en användare som installerat ts-fuse skulle kunna råka använda String schema klassen när den menar att ha typen string. Det är även möjligt då att en användare kollar på ett schema och ser att variabeln har typen String vilket skulle kunna få den att tro att det är en sträng. |
Schema.default(string) Tillåter ett schema att ha ett standardvärde ifall inget värde är satt ( undefined eller null). |
Method Names setDefault eller setDefaultValue hade kunnat vara tydligare sätt att förmedla methodens funktionalitet. |
Medans jag ser mycket positivt med flera utav de reglerna, så tycker jag att det ofta faktiskt är bättre om man bryter vissa regler. Så som jag gjorde i detta projektet med f vilket jag tog inspiration speciellt från zod för. Det har blivit ett vanligt sätt att skriva kod för mig och många andra, så det på sätt och vis förenklar arbetet med förkortningar som i sig egentligen inte betyder något.
En regel som jag känner är väldigt svår ibland är Make Meaningful Distinctions för tidigt i detta projektet och många andra så blir det ofta att man gör väldigt liknande saker på flera ställen. Så som i detta så har jag SchemaValidationResults och RequirementValidationResults vilket i sig inte är ett problem för det är nu tydligt vad som är vad, men det är efter att jag gjort en refactor från att ha alla validerings typer i en typ-fil och väldigt liknande namn.
| Metodnamn | Rader | Reflektion |
|---|---|---|
Schema.getValidationResults |
7 | Do One Thing Denna metoden - även om den är en utav mina längsta - så gör den ett jobb. Den tar in ett värde och validerar det - valideringen görs av andra metoder - och returnerar olika resultat beroende på valideringens resultat. |
Schema.addRequirement |
6 | Do One Thing Här bryter jag mot regeln, för denna metoden kollar först om en instans redan finns, annars skapar den en instans och lägger till. Den borde nog även heta något annat |
Requirement.combineRequirementValidationResults |
8 | Function Arguments Jag skulle säga att denna metoden, även om den har ett argument, så är det ett väldigt behövligt argument och ger en läsare mer behövlig information istället för att vara i vägen. |
StringRequirement.validate |
12 | Blocks and Indenting Jag har inte bara en rad innanför if-satsen, däremot är det flera rader för att göra koden mer lättläst. |
NumberIntegerRequirement.validate |
13 | Small Functions Denna metoden är inte liten, men det är mest på grund av retunerandet av resultat objektet. En möjlig lösning hade kunnat vara ha det misslyckade resultatet som en konstat eller ha en annan metod som generar den dynamiskt. |
Kapitel 3 är mycket enklare att hålla med om för jag - även om jag inte alltid är så bra på det - så uppskattar jag korta och abstrakta - men tydliga - metoder för de tillåter en att bygga ny funktionalitet på tidigare funktionalitet. Det är även mycket lättare att läsa och förstå vad som händer i en metod om den är kort och tydlig. Något som är mindre bra dock är just läsligheten utav koden. Om man kommer in i en ny kodbas för första gången och det bara är massor av, kanske tydliga, men abstrakta metoder som går vidare till fler abstrakta metoder så kan det vara svårt att förstå vad som händer.
När jag de senaste gått tillbaka och jobbat i äldre projekt så kan jag verkligen se att jag har - utan att ha gått denna kursen tidigare - arbetat mig mot liknande regler. Den största förändringen är nog hur jag i mina tidiga projekt skrev i princip all funktionalitet flera gånger på alla ställen den behövdes, hade minimal abstraktion och återanvändning av kod, men nu kommer uppdelning, i tjänster/klasser som tillåter mig att skriva koden en eller två gånger men använda den på flera sätt på flera platser, väldigt naturligt efter alla år.
En grej jag fortfarande har väldigt svårt för är open / closed principle. Att lägga till metoder är ju självklart, men att inte gå in och ändra på tidigare metoder kommer inte lika naturligt för mig. Det har hänt mig många gånger att jag ändrar på en retur och ser inte hur det påverkar annat på något dåligt sätt, men får senare ett telefonsamtal om att allting kraschat.
Jag tror överlag så kan jag skriva bra kod, men jag har verkligen inte tränat in alla regler. Testning är en sak som boken tar upp som jag verkligen aldrig gör om jag inte måste, anledningen är bara för att det är tråkigt, inte för att det är svårt eller att jag inte kan.