ああコード
コードを書くとき、私は自分が何をしているかを正確に知りたいです。たとえば、明日の朝のデモ用に一晩で書かれたコードは、システムのメインAPIになるコードとは大きく異なります。
この投稿では、さまざまな種類のコードについて説明し、デモの前夜と大規模なAPIの設計の両方に役立つヒントをいくつか紹介します。
「自分用」のコード
これは、1つの問題を一生に一度解決するコードです。 これは、たとえば、「スマートタスク」の解決策、それがどのように機能するかを確認するための複雑な関数の呼び出し、ファイル内の3つおきのポイントを削除するスクリプト、または新しい言語の「Hello、world！」 。そのようなプログラムの寿命はわずか数日であるため、それらを書くのは非常に簡単です。読みやすさ、コメント、入力データの検証、単体テストなどを心配する必要はありません。
このコードはバージョン管理システムに表示されることはありません。 さらに、このコードを他の開発者に見せないことを好みます。
プロトタイプコード
これは、いくつかの新機能の最小限の機能を実装する必要があるコードです。 これはほとんど何でも構いません。他の製品とのトライアル統合、基本的に新しい機能、および既存の製品の新機能。 多くの場合、プロトタイプの実装は短時間で完了する必要があります。適切なプロトタイプを時間通りに作成することは非常に困難です。 そのようなコードを開発するために、次のルールを作成しました。まず、コードは読み取り可能でなければなりません。 変数、クラス、関数、コーディング標準などの意味のある名前。次に、コメントは少なくとも最も複雑なセクションの近くにある必要があります。 第三に、期限が切れている場合、最も基本的な単体テストでのみ実行でき、実際には出力のチェックを気にしません。 プロトタイプがシステムの本格的な部分になると、これらすべてを追加できます。
別の重要なルールがあります。 プロトタイプが古いコードを変更する必要がある場合、変更にはコメントが必要です。 プロトタイプを作成した時点で変更は明らかであるかもしれませんが、数か月後、私が何をしたいかを理解することは非常に困難になります。 特にプロトタイプを捨てなければならなかった場合。
メインコード
これはシステム自体のコードです。 何がリリースされるか、QAがテストするもの、ユーザーが見るもの。このコードの作成方法についての本が書かれています。 私のお気に入りは、McConnellのCode Complete本です。
メインコードを作成するための一般的なルールについては説明しません。 ただし、コアコードの4つのカテゴリを強調したいと思います。
API
これは、他の人が使用するコンポーネントの一部です。 開発チームの各メンバーが独自のコンポーネントを作成し、使用するAPIの残りの部分を提供するのが本当に好きです。すべてのAPIメソッドとクラスには、最高のドキュメント、最も綿密なデータチェック、最も読みやすい単体テストが必要であることは明らかです。
そして、もちろん、API自体は使いやすいはずです。 Blochの「How to Design a Good API and Why It Matters」のプレゼンテーションをお勧めします 。
統合ポイント
同僚とコンポーネントを開発する場合、統合ポイントは、同僚が変更を統合するために変更する必要があるコードの部分です。 このような場所で最も一般的な解説は次のとおりです"//TODO: Your code here"
。
統合ポイントには、適切なドキュメントが必要です（APIほど細心の注意を払っていない場合があります）。 さらに、コンポーネントのその部分を統合する方法を明確にする必要があります。 例が役立つ場合があります。
別のクラス（またはファイル）で統合ポイントを強調表示することは非常に重要であるように思えます。 第一に、このコードは頻繁に変更されます。第二に、常に多くのエラーがあります。第三に、さらなる開発中に、すべての競合が（バージョン管理システムの意味で）これらのポイントで正確に発生します。
さらに、同僚が統合ポイントの外側のコンポーネントの一部を変更する必要がある場合、アーキテクチャに何か問題がある可能性が高くなります（コンポーネントが内部で緊密に接続されています）。
成長点
これはコンポーネントの一部であり、ほとんどの場合、新しい機能が追加されます。 たとえば、これはコンテキストメニューを作成するコードです。 システムが大きくなると、コンテキストメニューが増える可能性があります。 別の例：コンテンツ配信システム。 最初は1つしかサポートされていませんが、今後さらにいくつか追加される可能性があります。ファクトリメソッドと抽象ファクトリテンプレートがそのようなポイントに使用されることは明らかです。
一見したところ、コードのこれらの部分は、統合ポイントと大差ありません。 ただし、コンポーネント内の統合が通常、パーツを作成した2人によって1回実行される場合、異なるユーザーがコンポーネントを繰り返し拡張できます。 したがって、成長ポイントをAPIのように扱うようにします：綿密なドキュメント、入力の検証、多くの例。
別のカテゴリで成長ポイントを特に強調しました。 このコードが成長点であることを早期に理解することは非常に重要です。 この点をスキップすると、その後の追加ごとに新しいハックが追加されます。 クラス（またはファイル）に2000行を超える場合、これはおそらく実行中の拡張ポイントです。
さらに、他のコンポーネントへの依存関係が頻繁に現れるのは、これらのポイントです。 これは、別のクラス（またはファイル）で成長ポイントを強調することを支持するもう1つの引数です。
残りのコード
そして、それだけです。 このタイプのコードについて多くの記事が書かれています。 私はこのコードを書き、6か月後にそれを読んで喜んでいるようにします。おわりに
あなたが今書いているコードを知ることは非常に重要だと私には思えます。 これにより、開発プロセスが高速化され、コードが改善されます。強調する価値のある他のタイプのコードは何ですか？ たぶんあなたはいくつかのヒントを追加する必要がありますか？