コードを単純化しないでください

Ruby on Railsでの私の長年の作業を通して、私はいくつかの一般的な慣習を見てきました.
この本当に簡単なプラクティスは、彼らが害を与えないように見えるが、コードを読みやすくすることができ、冗長性を追加し、不要なコードを挿入することができます.

一つの表現方法
メソッドは、一連のプロセスや式をカプセル化することになっていますが、時には単一の論理単位を定義するために誤って使用されます.ほとんどの場合、開発者はコードをより読みやすくするためにこのメソッドを作成します.
次の例を考えてみましょう.

class User < ApplicationRecord
  before_save: setup_user

  def setup_user
    update_complexity
  end

  def update_complexity
    self.complex = true
  end
end

上の例を見た後に、setup_userのメソッドの中で割り当てを動かすことができるとき、なぜ2つの異なる方法で論理を切り離すべきかについて考えてください.

  def setup_user
    self.complex = true
  end

最初の例は、私たちのほとんどのために読みやすいですが、それは他の何かを行うことなく、別のものにリダイレクトするもう一つの方法を追加することによって、モデルに複雑さを追加します.
番目の例は、コード意図をすばやく理解し、モデルをきれいに保つのに十分読みやすいです.
DEVSは常に読みやすさを説明しなければならず、また、複雑さを保つことができます.

メソッド名、変数および定数を命名するときにモデル名をプリフィックス
変数、定数、メソッドを命名することは、基本的ではあるが苦しいことである.名前が彼らがそうするべきであるより多くを意味するとき、それはあまり大きくありません.
次の例を参照してください.

class User < ApplicationRecord
  USER_DEFAULT_ROLE = 'admin'
  ...
end

上の例では、ユーザーのデフォルトの役割を定数として定義しています.デフォルトのロールがユーザーモデルに属していることを知っています.なぜ?
この定数をモデルの範囲外で呼び出すと、このUser::USER_DEFAULT_ROLEのように呼びます.そして、あなたが見ることができるように、私たちは「ユーザ」という言葉を繰り返しています.それはコードの読みやすさに影響することができるように見えないかもしれませんが、同じモデルでいくつかの定数を持っているか、長いモデルと定数名を持っていると想像してください.

class CompanyConciliationFee < ApplicationRecord
  COMPANY_CONCILIATION_FEE_DEVELOPMENT_COST_RATIO = 0.59
  ...
end

私たちがモデルスコープの外からこの発明を定数と呼ぶなら、それがどのくらいに見えるかを見てください!MaintenanceFee::COMPANY_CONCILIATION_FEE_DEVELOPMENT_COST_RATIOはい、例は私が私の心に来た最初のものを書いたように見えるかもしれません.しかし、それは基本的にネーミング方法です.
人々がこれをするもう一つの理由は、彼らがモデルの範囲内で定数を使うことを考えているので、それがクラス名を接頭辞する必要がないでしょう.これはより簡単かもしれませんが、すべての定数が常に定義されているモデルに関連付けられていることを覚えておいてください.
モデルやクラスのプリフィックスは、定数、変数、メソッドで起こります.また、必要な場合でも、コードを乱雑にすることを心に留めておいてください.

エンドレスクラス
無限クラスリファレンスは、1つの式メソッドに似ているが、クラスを通して何かを参照します.
時々、私たちがコード構造を分解する必要がある仕事を得るために必要なクラス、すなわちサービス、プレゼンター、ポーラスのまたはどんな種類のコードカプセル化を使用することができますが、時々、我々は必要以上に使用することによって論理を伸ばして、したがって、複雑さを増やします.
次の例を見てください.

class UserGenerator
  def initialize(user)
  ...
  end

  def call
    UserAvatarUploader.new(user, avatar).call
  end

  def avatar
  ...
  end
end

class UserAvatarUploader
  ...

  def call
    AvatarUploader.new(:user, user, avatar)
  end
end

class AvatarUploader
  ...

  def call
    user.update(avatar: avatar)
  end
end

あなたがユーザーを作成して、アバターをアップロードするプロセスに従うならば、あなたは我々が実際に3つの異なるサービスを使用していることを観察することができます1つの単純なものをして、アバターをアップロードしてください.
この例は、毎日何千人もの人々が使用する生産コードベースで起こることの非常に基本的で簡素化されたバージョンです.ユーザーは注意しないでください、しかし、DEVSはデバッグのときに、彼らがアバターがアップロードされるコードのどこにあるかを理解するために無限のクラスリファレンスに従わなければならないとわかるためにだけに苦しみます.
私たちはそれらすべてのクラスを必要としません.シンプルに保つ.あなただけの仕事は、アバターをアップロードするには、キスの原則に従って、1つのサービスでそれを維持する場合は、他の必要はありません!あなたがサービス責任を切り離していると感じるかもしれません、しかし、あなたが実際にしていることはあなたのJam Teammate生活を非常に不快なものにすることです.
そこには・・・私はしばしばRuby on Railsのコードベースを参照してください.あなたはどう思いますか.あなたは、我々のコードを単純化するのを避けることができるもう一つの一般的な単純な実行について知っていますか?