Rälsutveckling: kodningskonventioner och bästa praxis

Vad finns i ett namn

A good name answers important questions. What does it contain? What does it mean? How would I use it?
What  role  does  it  play?
Always name your methods based on their behaviour, not implementation.
Consider,

By looking at the method name above, we can predict it’s going to perform 2-3 database operations, but
when I’m working in Business model, why would it concern me?
Going  by,  naming  method  based  on  their  business  role,  the  method  can  be  renamed  as,

Strukturell namngivning

Another common strategy is to name things for their role in the program. It’s the input or the output. It’s the recurring phrase or the middle sentence.  Consider the code for counting differences between two points;

Here the arguments first and second are pretty vague, considering the fact that we’re not even sure if the order matters. In this context, it doesn’t.
I can then restructure my code as;

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.

Refactoring is about recognizing a snippet of code as exhibiting characteristics that are known to be problematic.Applying a change that is known to fix this category of problem.
This problematic pattern is called Code Smell, “code smell is a surface indication that usually corresponds to a deeper problem in the system.” – Martin Fowler
Starting small is never a bad idea, if you can refactor code at micro level, then when it all comes together, it will become a refactored code.
Consider two code snippets for example,

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

• What if we devise a set of rules to follow while coding, that later on reduces our efforts in refactoring.
  The most basic and important point is FORMATTING. It sounds like the most obvious and easy thing to do but it’s very important to format your code correctly. In terms of code readability, understanding for future references, and also while resolving conflicts that occur while merging two different branches.
• 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.
• FORMATING: there are certain gems which makes your life much easier : 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 ; -> link_helper      –> 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