Sviluppo delle rotaie: convenzioni di codifica e migliori pratiche

Cosa c'è in un nome

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,

Denominazione strutturale

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;

Ciò che possiamo concludere da ciò è che il primo passo è stato descrivere il problema in inglese. Il calcolo della distanza tra due filamenti riguarda il conteggio delle mutazioni incontrate tra i due filamenti.

Refactoring

La riorganizzazione del codice è generalmente piuttosto banale. La parte difficile è sapere da dove cominciare e riconoscere che puoi farcela. Parte del superamento di quella barriera consiste semplicemente nel farlo alcune volte. Trova un condizionale e, per ciascuno dei suoi blocchi, crea un oggetto la cui unica responsabilità è fare quella cosa.

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,

Qual è la somiglianza tra le parti di codice sopra? Entrambi hanno ciascun loop e se proviamo a trovare il loro odore di codice,

• Un ciclo con una variabile temporanea.
• Un ciclo con un condizionale annidato.

Proviamo a refactoring

Il primo ciclo ha solo una variabile temporanea, che può essere corretta utilizzando 'inject'

Questo ha due variabili temporanee e un ciclo annidato, poiché stiamo cercando di classificarle, sort_by dovrebbe funzionare!. Il codice può essere ulteriormente sottoposto a refactoring, poiché stiamo cercando di trovare il valore massimo, possiamo utilizzare direttamente la funzione max_by qui,

Pratiche generali

• 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.
• Quando scrivi una condizione if con più sottocondizioni, prova sempre a ordinarle in modo tale da richiedere il minimo sforzo. Per esempio,

• Se hai una grossa parte di logica, che ruoterà attorno a una singola funzionalità, prova a suddividerla in più metodi più piccoli. Aumenta la riusabilità, inoltre diventa facile per un nuovo sviluppatore comprendere facilmente il codice. Invece di scrivere tutto in un unico metodo e dargli l'aspetto di una logica complessa, dividilo in blocchi di metodi più piccoli e leggibili.
• Commenta il tuo codice magico. Ruby fornisce molti metodi di metaprogrammazione, che aiutano a ridurre i tuoi sforzi e riducono il tempo. Ma non sono sempre così facili da capire quando vuoi farvi riferimento, è sempre una buona idea aggiungere commenti appropriati in modo che quando torni più tardi a dare un'occhiata, sarà più facile riconnetterti.
• Usa before_filter, invece di ripeterti nel controller.
• Utilizzare i callback del modello per evitare di scrivere troppo codice nei controller per le azioni che ruotano attorno alle operazioni CRUD di base.
• FORMATING: there are certain gems which makes your life much easier : awesome_print ; pretty print ;  rubocop.
• Segui sempre la pratica della Code Review in Git. Il codice scritto da uno sviluppatore dovrebbe essere rivisto da altri membri del team prima di unirlo ai rami principali, poiché ciò aiuta a eliminare eventuali errori potenziali o risultati imprevisti. Aiuta anche a mantenere ogni membro informato e aggiornato su ciò su cui sta lavorando il suo collega.
• Le istruzioni che estendono oltre 80 caratteri dovrebbero essere suddivise nelle righe successive in modo da evitare la barra di scorrimento durante la visualizzazione del codice in altri mezzi come GitHub.
• Quando inserisci il codice nel tuo repository, git diff mi dice cosa hai fatto, il tuo messaggio di commit dovrebbe dire perché l'hai fatto.
• NON OTTIMIZZARE per le prestazioni – OTTIMIZZARE PER LA CHIAREZZA DEL CODICE
• Il test unitario è sempre una buona idea per garantire che la funzionalità funzioni come previsto. Aiuto per aspetto: Rails per impostazione predefinita genera un helper per ogni controller. Eliminali e prova a utilizzare aiutanti orientati agli aspetti come ; -> link_helper      –> menu_aiuto
• Secondo la convenzione di MVC, si dovrebbe evitare di effettuare chiamate al database dal livello Visualizza. Sposta quella parte del tuo codice nei controller per garantire la separazione delle preoccupazioni.
• Ridurre le chiamate ai database. Se una pagina visitata spesso genera più di un paio di chiamate al DB, vale la pena dedicare un po' di tempo a ridurre il numero di chiamate a poche. In molti casi, è solo questione di usare .includes() o .joins().
• Diventa un compito noioso controllare di tanto in tanto la struttura del modello, quindi includi la struttura del modello nella parte superiore del file come riferimento.

Spero che questo abbia aiutato! Firmando, Niyanta

Salva

Salva

Salva

Salva

Salva

Salva