計算を表す長いコードを読みやすくすることは可能ですか？

長いメソッドは一般的に悪いと考えられていますが、私のコードには理解しにくい長いメソッドがあります（50行以上）。内部の単一のステートメントはすでに50行を超えているため、これらのメソッドを読みやすくするのに苦労しています。その単一のステートメントを読み取るのは、ORMを使用してデータベースクエリを作成し、特定のジョブを実行することです。メソッド名に明記。ステートメントが複数の列に結合し、複数のwhereを適用し、複数の異なる列を選択して必要な文書化された出力形式を作成するため、ステートメントが非常に長い理由。

そのような読みにくいコードは悪いコードと見なされますか？同様に、複雑なアルゴリズムのコードを記述して、明確に名前が付けられたメソッドでラップされた読みにくいコードを生成した場合、そのコードは悪いコードですか？

あなたが書いた

そのような読みにくいコードは悪いコードと見なされていますか

ですから、コードが読みにくいこと、そして読みにくいとメンテナンスや進化が難しいことに間違いなく同意することになります。そのため、あなた自身の方法では、コードが「悪い」ものであると考えていると思います。ただし、50行のSQLステートメントのようなものを改善する方法が明確でない場合があります。簡単な「抽出メソッド」リファクタリングは機能せず、コードを読みやすくするためのどこから始めればよいのかおそらく手がかりがありません。これらの場合でも、次のいずれかまたはすべてを試すことができます

• コードのクリーンアップであなたよりも経験豊富な誰かにコードを見せてください。組織内に質問できる人がいない場合は、codereview.stackexchangeを試してください。

• 特定の問題についてグーグルしようとします。たとえば、「長いSQLステートメントをクリーンアップする」のようなものから始めるのがよいでしょう。あなたはそのトピックについて見つけた記事の数に驚かされ、あなたのケースのための頭の悪いレシピが見つからなくても、あなたはいくつかの新鮮なアイデアを得るかもしれません

• できないことの正当化を求めるのではなく、適切な改行、適切なインデント、説明コメントの追加、いくつかの変数の改善など、コードをクリーンアップするためにできることに焦点を当てます名前。このプロセス中に、コードの詳細を再読み取りすることを強いる可能性は低くありません。コードを小さな単位にリファクタリングする方法を見つけます

• 練習、練習、練習。「クリーンコーディング」は1日で習得できるものではなく、経験を重ねることで簡単になります。今日、問題の解決策が見つからないかもしれませんが、数か月後にコードに戻ったとき、それはあなたには違って見えます。

読みにくいのは悪くない-不必要に読みにくいのは悪い。

いくつかのものは、単にある難しいです。その場合、問題を完全に理解し、コードを記述し、できる限りコメントを付けて、次の開発者にチャンスを与える必要があります。

しかし、あなたがそれらを困難にしたために、いくつかのことが難しいだけです。問題を単純化して簡単にできる場合は、単純化します。理解するのは難しいが、サブ問題に合理的に分割できる場合は、それをサブ問題に分割して簡略化します。

ORMでレポートを作成するには？マジ？SQLを学んでください。手続き型言語はこの種のことでひどいです。

SQLは、複雑な結合と選択を処理するように設計された言語です。SQLが美しく見えなくても、データベースオブジェクトを図にドラッグアンドドロップできるあらゆる種類の視覚化ツールがあり、SQLが生成されます。言うまでもなく、クエリの調整と最適化、そのクエリプランの表示、プラットフォームに追加のインデックス作成オプションの提案などを行うことができます。これは非常に柔軟性があります。

ここの一部の人々は私に同意しないと思いますが、ORMは複雑なレポート目的には適していません。可能であれば、それから離れて構造化クエリ言語に移行することを検討します。

一般に、コードを読むのが難しいのは悪い考えです。たとえあなたが唯一のメンテナーであっても、私は数年または数週間後にいくつかのコードに戻って、頭を動かすのが難しいと感じることが何度かありました。

1つのクエリで多くのことを行う必要がある場合は、コメントを埋め込んだ行に分割してみてください。

query(join(map(condition1, condition2), blah, blah, something(bah, blah, blah))) 

になる：

// Why are we doing such an awful single query rather than a sequence of selects?
query( // Description of query
  join( // Why are you doing a join here
    map( // Why a map
      condition1, // What is this
      condition2  // And this
   ), // End Map
   blah, // What, Why?
   blah, // What, Why?
   something( // What does this do?
      bah, // What, Why?
      blah, // What, Why?
      blah // What, Why?
      ) // End Something
   ) // End Join
) // End Query

@DocBrownの優れた回答に加えて、誰もが常に「良い」コードを書いていないことを認識する価値があります。コーディングはトレードオフを引き起こし、多くの場合、あなたがあなたが望むよりも少しクリーンでないものを書いたことを受け入れて、後でそれに戻ってくる方が良いです。リファクタリングは、時間の経過とともにコードを改善するプロセスです。私の経験では、それが「初めて正しくなる」のではなく、優れたコードベースを作るものです。

そして、個々のメソッド/コード行のレベルではなく、アプリケーションのレベルでコードを評価します。したがって、複雑なメソッドがあり、それが明確に名前が付けられている場合、メソッドがまとまりがある限り、「悪い」コードはないと思います。

名前付けは、コードをわかりやすくするための最大の武器です。メソッドに名前を付けて、コードを読んでいる人が必要に応じて本文をスキップできるようにします。変数などに名前を付けるのは、割り当てステートメントを読まなくても、読者がそれらが表すものを確認できるようにするためです。

次のことは、メソッドが本当に1つのことだけを実行するようにすることです。副作用によってコードが理解しにくくなります。したがって、メソッドが出力形式のデータを返す場合、データベースのステータスを「印刷済み」などに更新すべきではありません。

レイヤー化/コンポーネント化は、次のことを行う可能性があります-ORMの結果を生成する複雑なメソッドがたくさんある場合は、それらをバンドルして、コードの読者がすべて同じように動作し、副作用がないと想定できるようにします。