Rails 開発: コーディング規約とベスト プラクティス

名前って何

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,

構造の命名

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;

このことから言えることは、最初のステップは問題を英語で説明することであったということです。 2 つの鎖の間の距離の計算は、2 つの鎖の間で発生する突然変異の数に基づいて行われます。

リファクタリング

コードを再配置することは通常、非常に簡単です。難しいのは、どこから始めればよいのかを知り、それができると認識することです。その壁を乗り越えるには、それを数回繰り返すだけです。条件文を見つけて、そのブロックごとに、その処理のみを担当するオブジェクトを作成します。

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,

                      

上記のコード部分の類似点は何ですか?どちらにもそれぞれのループがあり、コードの匂いを見つけてみると、

• 一時変数を使用したループ。
• ネストされた条件を含むループ。

それらをリファクタリングしてみましょう

最初のループには一時変数のみがあり、「inject」を使用して修正できます。

これには 2 つの一時変数と入れ子になったループがあり、それらをランク付けしようとしているので、sort_by は機能するはずです。コードはさらにリファクタリングできます。最大値を見つけようとしているため、ここで max_by 関数を直接使用できます。

一般的な慣行

• 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.
• 複数のサブ条件を含む if 条件を作成する場合は、必要な労力が最小限になるように条件を順序付けるようにしてください。例えば、

• 単一の機能を中心に展開する大きなロジックの塊がある場合は、それを複数の小さなメソッドに分割してみてください。再利用性が高まるだけでなく、新しい開発者でもコードを簡単に理解できるようになります。すべてを 1 つのメソッドで記述し、複雑なロジックの外観と雰囲気を与えるのではなく、メソッドを読みやすい小さな部分に分割します。
• マジックコードをコメントしてください。 Ruby は、労力を軽減し、時間を節約するのに役立つメタプログラミング手法を多数提供します。ただし、後で参照したいときに必ずしも理解しやすいとは限りません。適切なコメントを追加して、後で戻って確認するときに再接続しやすくすることをお勧めします。
• コントローラーで同じことを繰り返す代わりに、before_filter を使用してください。
• モデル コールバックを使用して、基本的な CRUD 操作を中心とするアクションのコントローラーにコードを書きすぎないようにします。
• FORMATING: there are certain gems which makes your life much easier : awesome_print ; pretty print ;  rubocop.
• Git でのコード レビューの習慣には常に従ってください。 1 人の開発者によって書かれたコードは、メイン ブランチとマージする前に他のチーム メンバーによってレビューされる必要があります。そうすることで、潜在的なエラーや予期しない結果を排除することができます。また、同僚が取り組んでいることについてすべてのメンバーに情報を提供し、最新情報を提供し続けるのにも役立ちます。
• GitHub などの他の媒体でコードを表示するときにスクロールバーが表示されないように、80 文字以降を拡張するステートメントは次の行に分割する必要があります。
• コードをリポジトリにコミットするとき、git diff は何をしたかを教えてくれます。コミット メッセージにはその理由が示されます。
• パフォーマンスのために最適化するのではなく、コードの明確さのために最適化する
• 機能が期待どおりに動作していることを確認するには、単体テストを常に行うことをお勧めします。アスペクトによるヘルプ: Rails はデフォルトでコントローラーごとに 1 つのヘルパーを生成します。それらを削除し、次のようなアスペクト指向のヘルパーを使用してみてください。 -> link_helper      –> メニューヘルパー
• MVC の規則に従って、ビュー層からデータベースを呼び出すことは避けるべきです。コードのその部分をコントローラーに移動して、懸念事項を確実に分離します。
• データベースへの呼び出しを減らします。頻繁にアクセスするページによって DB への呼び出しが 2 ～ 3 回発生する場合は、少し時間をかけて呼び出し数を数回に減らすことをお勧めします。多くの場合、これは .includes() または .joins() を使用するだけの問題です。
• モデル構造を時々チェックするのは面倒な作業になります。そのための手段として、ファイルの先頭にモデル構造を参照として含めます。

お役に立てば幸いです!サインオフ、 ニヤンタ

保存

保存

保存

保存

保存

保存