Rälsutveckling: kodningskonventioner och bästa praxis

Vad finns i ett namn

Ett bra namn ger svar på viktiga frågor. Vad innehåller det? Vad betyder det? Hur skulle jag använda det?
Vilken roll spelar den?
Namnge alltid dina metoder baserat på deras beteende, inte implementering.
Tänk på det,

Genom att titta på metodnamnet ovan kan vi förutsäga att den kommer att utföra 2-3 databasoperationer, men
när jag arbetar i affärsmodellen, varför skulle det beröra mig?
Genom att namnge metoden baserat på deras affärsroll kan metoden döpas om till,

Strukturell namngivning

En annan vanlig strategi är att namnge saker efter deras roll i programmet. Det är inmatningen eller utmatningen. Det är den återkommande frasen eller mittmeningen. Tänk på koden för att räkna skillnader mellan två punkter;

Här är argumenten ett och två ganska vaga, med tanke på att vi inte ens är säkra på om ordningen spelar någon roll. I det här sammanhanget gör det inte det.
Jag kan då omstrukturera min kod som;

Vad vi kan dra slutsatsen av detta är att det första steget var att beskriva problemet på engelska. Avståndsberäkning mellan två strängar handlar om antalet mutationer som påträffas mellan de två strängarna.

Refaktorering

Att ordna om koden är i allmänhet ganska trivialt. Den knepiga delen är att veta var man ska börja och inse att man kan göra det. En del av att komma över den barriären är helt enkelt att göra det några gånger. Hitta ett villkorligt, och för vart och ett av dess block, skapa ett objekt vars enda ansvar är att göra den saken.

Refaktorisering handlar om att identifiera en kodsnutt som uppvisar egenskaper som man vet är problematiska och att tillämpa en förändring som man vet löser den här typen av problem.
Detta problematiska mönster kallas Code Smell, "kodlukt är en ytlig indikation som vanligtvis motsvarar ett djupare problem i systemet." - Martin Fowler
Att börja smått är aldrig en dålig idé, om du kan refaktorisera kod på mikronivå, så kommer det att bli en refaktoriserad kod när allt kommer samman.
Tänk till exempel på två kodsnuttar,

Vad är likheten i kodbitarna ovan? Båda har varje slinga, och om vi försöker hitta deras kodlukter,

• En loop med en temporär variabel.
• En slinga med en kapslad villkorlig.

Låt oss försöka omstrukturera dem

Den första slingan har bara en temporär variabel, som kan fixas med "injicera"

Den här har två temporära variabler och en kapslad loop, eftersom vi försöker rangordna dem borde sort_by fungera!. Koden kan omfaktoreras ännu mer, eftersom vi försöker hitta maxvärdet kan vi direkt använda max_by-funktionen här,

Allmän praxis

• Vad händer om vi tar fram en uppsättning regler att följa när vi kodar, som senare minskar vårt arbete med refaktorisering.
  Den mest grundläggande och viktigaste punkten är FORMATERING. Det låter som den mest uppenbara och enkla saken att göra, men det är mycket viktigt att formatera koden korrekt. Både för att koden ska vara läsbar och begriplig för framtida referenser, men också för att lösa konflikter som uppstår när två olika grenar slås samman.
• När du skriver ett if-villkor med flera undervillkor, försök alltid beställa dem så att minsta ansträngning krävs. Till exempel,

• Om du har en stor del av logik, som kommer att kretsa kring en enda funktionalitet, försök att dela upp det i flera mindre metoder. Det ökar återanvändbarheten, plus att det blir lätt för en ny utvecklare att enkelt förstå koden. Istället för att skriva allt i en enda metod och ge det utseendet och känslan av en komplex logik, dela upp det i mindre läsbara bitar av metoder.
• Kommentera din magiska kod. Ruby tillhandahåller många metaprogrammeringsmetoder, som hjälper till att minska din ansträngning och är tidsvänliga. Men de är inte alltid så lätta att förstå när du vill hänvisa tillbaka till dem, det är alltid en bra idé att lägga till lämpliga kommentarer så att när du kommer tillbaka senare för att ta en titt, blir det lättare för dig att återansluta.
• Använd before_filter, istället för att upprepa dig själv i kontrollern.
• Använd modellåterkallningar för att undvika att skriva för mycket kod i kontroller för de åtgärder som kretsar kring de grundläggande CRUD-operationerna.
• FORMATERING: det finns vissa ädelstenar som gör ditt liv mycket enklare : awesome_print ; pretty print ; rubocop.
• Följ alltid praxis för Code Review i Git. Kod som är skriven av en utvecklare bör granskas av andra teammedlemmar innan de slås samman med huvudgrenarna, eftersom det hjälper till att eliminera eventuella fel eller oväntade resultat. Det hjälper också till att hålla varje medlem informerad och uppdaterad om vad deras kollega arbetar med.
• Påståenden som utökar post 80-tecken bör delas upp i nästa rader för att undvika rullningslist när du tittar på kod i andra medier som GitHub.
• När du skickar koden till ditt arkiv berättar git diff för mig vad du gjorde, ditt commit-meddelande bör säga varför du gjorde det.
• OPTIMERA INTE för prestanda – OPTIMERA FÖR TYDLIGHET I KODEN
• Enhetstestning är alltid en bra idé för att säkerställa att funktionaliteten fungerar som du förväntade dig. Hjälp från aspekter: Rails genererar som standard en hjälpare för varje styrenhet. Eliminera dem och försök använda hjälpare som är aspektorienterade som ; -> länk_hjälpare -> menu_helper
• Enligt MVC-konventionen bör man undvika att göra anrop till databasen från View-skiktet. Flytta den delen av din kod till kontroller för att säkerställa separation av bekymmer.
• Minska anrop till databaser. Om en ofta besökt sida utlöser fler än ett par samtal till DB är det värt att lägga ner lite tid på att minska antalet samtal till ett fåtal. I många fall är detta bara en fråga om att använda .includes() eller .joins().
• Det blir en tråkig uppgift att kontrollera din modellstruktur då och då, som en utväg till det, inkludera din modellstruktur högst upp i filen som referens.

Hoppas det hjälpte! Loggar ut, Niyanta

Spara

Spara

Spara

Spara

Spara

Spara