低品質のコードに同意しますか？

遅かれ早かれ、すべてのプログラマーは良質のコードを書くという問題に直面します。 しかし、この品質の背後にあるものは何ですか？ 間違いがない？ 適切に設計されたフィールド名とメソッド名？ ディレクトリ内のプロジェクトファイルのハード配布？





Steve McConnellによると、システムの品質は開発コストを削減します。 独自のコードの理解に費やす労力が少ないほど、新しい機能を簡単に追加できます。 そして、結果として、コードの絡み合いが少ないほど、品質が高くなります。 多くの開発者は繰り返します：「将来コードを理解しやすくするために、「命名規則」を開発する必要があります。」 このような合意は理にかなっていますが、コードの品質に間接的に関連しています。



複雑なアプリケーションの開発の初期段階で、主要な開発者とプロジェクトマネージャーは、「CNC」と略される「コーディングと命名規則」を採用する問題をチームに提起します。 したがって、彼らは実際、「宗教」戦争の許可を与えます。 契約は、開発者の1人の経験、好み、習慣を文書化する方法です。 ほとんどの場合、主要な開発者の経験が文書化されています（課されています）。 それ以外の場合、契約の数はチームメンバーの数と等しくなります。 多くのチームは、意見の相違を避けるために、信頼できるソース（Java、.Net）が推奨する契約を選択します。 チームが企業標準レベルで契約を受け入れる場合のオプションもあります。



契約を受け入れるプロセスを横から見ると、逆説的な状況が起こっていることがわかります。チームは、契約の本質は名前と権限ではなく、サポートを促進し、書かれたコードの意味を伝えることを忘れています。 ロシア語から類推してみましょう。 文法と句読点は何らかの合意です。 しかし、もしそうなら、それから私は名前で契約を終えました。 しかし、意味は明確であり、簡単に変更できます。



契約書を書く際のコードの純度を追求する上で、セマンティックではなくスタイルのデザインに従うと結論付けることができます。 合意が私たちの経験に反する場合、つづりを間違えます。



合意ではなく、開発者が保守、保守、および開発を容易にするコードを記述するために学習し使用する必要がある原則を決定することがより重要です。 基本原則は、コミュニケーション、シンプルさと柔軟性です。



最初のガイドに従って、あなたが書いたコードを他の人が読んで理解できるかどうかを常に考えてください。 2番目の原則は、最も単純なソリューションを選択し、複雑な機能（たとえば、10行以上の方法）をいくつかの単純な機能に分解する必要があることを示唆しています。 柔軟性は最も複雑な原則であり、その実装のために、デザインパターンに目を向けることを提案します。



これらの原則に基づいて、私たちはもはや文体的なCNCを構築することはできませんが、セマンティックです。 間接的に、そのような合意は、Steve McConnellによる「Perfect Code」という本で説明されています。 ケントベックは、3つの原則の実装についてさらに詳しく語っています。



私の実際の授業では、数学では広く使用されている「反対から」という、別の重要なアプローチを選びました。 肯定的な声明の形で合意を定義し、明白な否定的な効果を持たない構造の濫用の事例を特定しません。 そのような場合は、潜在的にコードが複雑になるだけです。 それらは「匂い」と呼ばれます。 したがって、すべてのプログラマーが外見を許可すると、雪だるまのように蓄積されます。 その結果、数か月の開発の後、「契約」に関して正しいコードは、意味に関して完全に読めなくなります。 セミナーでは、匂いカタログに基づいて形成されるべき新しい合意を採択するようにチームを招待します。 リファクタリングと匂いの処理のトピックを取り上げた最初の著者の1人は、Martin Fowlerです。



コードの品質を向上させるには、正式な「命名契約」に限定するだけでは不十分です。 品質改善は複雑なプロセスであり、開発者の継続的な開発、新しい契約（形式と意味の両方）の採用、および作業の適応原則が必要です。



この記事の著者であるDenis Millerは、ソフトウェア開発の分野におけるアジャイル方法論に関するトレーナーおよび独立コンサルタントです。 主な関心分野：開発プロセスの改善とプログラマー向けコードの品質の改善。