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

名前って何

良い名前は重要な質問に答えてくれる。その名前には何が含まれているのか？どういう意味なのか？どのように使うのか？
どのような役割を果たすのか？
メソッドの名前は、実装ではなく、常にその動作に基づいて付ける。
考えてみよう、

上記のメソッド名から、このメソッドは2-3のデータベース操作を実行することが予測できるが
ビジネスモデルで仕事をしているのに、なぜそんなことが気になるんだ？
ビジネス上の役割に基づいたメソッドの命名によって、メソッドは次のように改名される、

構造の命名

もうひとつの一般的な戦略は、プログラムにおける役割に応じた名前をつけることだ。それは入力であったり出力であったりする。繰り返し出てくるフレーズや真ん中の文。 2点間の差を数えるコードを考えてみよう；

ここでは、順番が重要かどうかさえ分からないという事実を考慮すると、第一と第二の議論はかなり曖昧だ。この文脈では、それは重要ではない。
そうすれば、私のコードをこう再構築することができる；

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

リファクタリング

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

リファクタリングとは、コードのスニペットに問題があることが分かっている特徴があることを認識し、この問題のカテゴリーを修正することが分かっている変更を適用することである。
この問題パターンはコード・スメルと呼ばれる。"コード・スメルとは、通常、システムのより深い問題に対応する表面的な兆候である"- マーチン・ファウラー
ミクロのレベルでコードをリファクタリングできれば、すべてがまとまったときにリファクタリングされたコードになる。
例えば、2つのコード・スニペットを考えてみよう、

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

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

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

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

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

一般的な慣行

• もし、コーディング中に従うべき一連のルールを考案したらどうだろう。そうすることで、後でリファクタリングの労力を減らすことができる。
  最も基本的で重要なポイントは、フォーマットです。最も明白で簡単なことのように聞こえるが、コードを正しくフォーマットすることは非常に重要だ。コードの読みやすさ、将来の参照のための理解、そして2つの異なるブランチをマージする際に発生するコンフリクトを解決するためにも。
• 複数のサブ条件を含む if 条件を作成する場合は、必要な労力が最小限になるように条件を順序付けるようにしてください。例えば、

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

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

保存

保存

保存

保存

保存

保存