私は短い締め切りで多くのプロジェクトを行う傾向があり、二度と使用されることのない多くのコードを使用するため、手抜きをするというプレッシャーや誘惑が常にあります。私がいつも守っているルールの 1 つは、カプセル化/疎結合です。そのため、1 つの巨大な God クラスではなく、小さなクラスをたくさん持っています。しかし、他に決して妥協すべきではないものは何ですか?
更新- 素晴らしい反応をありがとう。多くの人が単体テストを提案していますが、それは私が行っている種類の UI コーディングにはあまり適していないと思います。ユーザビリティ/ユーザー受け入れテストは非常に重要なようです。繰り返しますが、私が話しているのは、締め切りが不可能なプロジェクトのための最小限のコーディング標準です。
OOP ではありませんが、短期的にも長期的にも役立つプラクティスは、DRY (Don't Repeat Yourself) です。コピー/貼り付けの継承を使用しないでください。
OOP の実践ではなく、常識です ;-)。
お急ぎの場合は、ハックを作成する必要があります。必ず理由とともにコメントを追加してください。そのため、後でトレースして、適切なソリューションを作成できます。
戻ってくる時間がなかった場合は、いつでもコメントが表示されるので、現時点でそのソリューションが選択された理由がわかります。
ソース管理を使用します。
セットアップにどれだけ時間がかかっても（数秒..）、常にあなたの人生を楽にしてくれます！（まだOOP関連ではありません）。
ネーミング。プレッシャーがかかると、文書化する時間もコメントする時間もないひどいコードを書くことになります。変数、メソッド、およびクラスにできるだけ明示的に名前を付けると、追加の時間がほとんどかからず、修正が必要なときに混乱が読みやすくなります。OOP の観点からは、クラスに名詞を使用し、メソッドに動詞を使用することは、カプセル化とモジュール化に自然に役立ちます。
単体テスト - 夜の睡眠に役立ちます :-)
これはかなり明白ですが (希望します)、少なくとも、パブリック インターフェイスが可能な限り正しいことを常に確認しています。クラスの内部は、後でいつでもリファクタリングできます。
ある時点でコードを読んで理解しなければならない人々 (あなたの将来の自分でさえあるかもしれません) について考えてみてください。
変更可能なパブリック変数 (構造体のような) を持つパブリック クラスはありません。
気が付く前に、コード全体でこのパブリック変数を参照し、このフィールドが計算されたものであり、ロジックが必要であると判断した日... リファクタリングが面倒になります。
その日がリリース日より前である場合は、さらに厄介になります。
単一責任プリンシパルの適用。このプリンシパルを効果的に適用すると、多くの正の外部性が生成されます。
もちろん、すべてをユニットテストし、適切に設計し、コメントを付け、ソース管理にチェックインし、バグがないようにする必要があります。しかし、人生はそのようなものではありません。
私の個人的なランキングはこれです：
これについてはすでに言及されていることは承知していますが、主観的な問題なので、ランキングを追加したいと思います。
他のみんなと同じように、OOP の実践ではなく、OOP に適用されるコーディングの実践です。
他にも「すべき」は無数にあると思いますが、上位3つを挙げるとしたら、それがリストになります。
コメントに応じて編集： これがまさに、これらのことを前もって行う必要がある理由です。これらすべての種類のプラクティスにより、継続的なメンテナンスが容易になります。プロジェクトのキックオフでより多くのリスクを想定するほど、コードの保守により多くの時間を費やす可能性が高くなります。確かに、初期費用は高くなりますが、強固な基盤の上に構築することで元が取れます。あなたの障害は時間の不足 (つまり、他のアプリケーションを維持しなければならないこと) ですか、それとも上層部からの決定ですか? 私はこの種の慣行を採用できるようにするために、これらの両方の前線と戦わなければなりませんでしたが、それは楽しい状況ではありません.
数日/数週間前に作成したコードに戻り、20分かけて自分のコードを確認します。時間の経過とともに、「オフザカフ」コードが将来の保守作業のために十分に編成されているかどうかを判断できるようになります。そこにいる間に、リファクタリングと名前変更の機会を探します。
最初に関数に選択した名前が、最終的な形式の関数に完全に適合していないことに気付くことがあります。リファクタリングツールを使用すると、広く使用される前に名前を簡単に変更できます。
私が常に時間を割いている実際の OOP プラクティスは、Single Responsibility Principleです。これは、プロジェクトが「ライブ」になった後でコードを適切にリファクタリングすることが非常に難しくなるためです。
この原則に固執することで、私が書いたコードは、機能要件または非機能要件に一致しない場合に、簡単に再利用、置き換え、または書き直せることがわかりました。複数の責任を持つクラスになると、要件を満たしているクラスもあれば、満たしていないクラスもあり、全体が完全に不明確になる可能性があります。
この種のクラスは、「修正」によって何が壊れるか分からないため、維持するのにストレスがかかります。
[定型文の非 OOP 固有の警告をここに挿入]
関心の分離、単体テスト、そして何かが複雑すぎる場合、おそらくまだ完全に概念化されていないという感覚。
UML スケッチ: これにより、無駄な労力が何度も明確になり、節約されました。写真は素晴らしいですね。:)
is-a と has-a について本当に考えています。最初にこれを正しく行うことが非常に重要です。
他の誰もが示唆しているように、これらの推奨事項は OOP に固有のものではありません。
コードにコメントを付け、わかりやすい名前の変数を使用してください。あなたが書いた簡単で汚いコードを振り返る必要がある場合は、簡単に理解できるはずです。私が従う一般的なルールは次のとおりです。すべてのコードを削除してコメントだけを残したとしても、プログラムの流れは理解できるはずです。
通常、ハックは複雑で直感的でない傾向があるため、適切なコメントが不可欠です。
また、通常、締め切りが迫っている場合は、最も一般的なタスクに基づいてコード ライブラリを作成することをお勧めします。これにより、プロジェクトのたびに車輪を再発明するのではなく、「点をつなぐ」ことができます。
よろしく、
ドクター
会社がどれだけ早くそれを望んでいても、私はほとんどの場合、自分の能力を最大限に発揮してコードを書こうとしています。
短期間であっても、それ以上かかることはなく、通常は多くの時間を節約できます。
私はコードを書いたことを覚えておらず、二度と見たこともありません。私は常にコードをテストしてデバッグするために数回パスを作成します。それらの数回のパスでも、コードを DRY に保つためのリファクタリングなどのプラクティスを行います。程度）、関心の分離と結束はすべて時間を節約するようです。
これには、ほとんどの人よりも多くの小さなクラスを作成することが含まれます (クラスごとに 1 つの懸念事項をお願いします)。多くの場合、初期化データを外部ファイル (または配列) に抽出し、そのデータ用の小さなパーサーを作成します。手。
コーディング自体は非常に迅速かつ簡単です。「プレッシャーにさらされている」ときに誰かが書いたがらくたをデバッグするには、常に時間がかかります。
現在のプロジェクトを開始してからほぼ 1 年が経ち、ようやく新しいコミットをテスト サーバーにプッシュする自動ビルドをセットアップしました。私が早い段階で犯した最大の過ちは、暗くなることでした。すべての機能、機能強化、バグ修正などで、製品を誰かに見せる前に「あと 1 つだけ」という悪いケースがあり、文字通り 6 か月のサイクルに渦巻いていました。すべての合理的な変更が自動的に押し出されていたら、私が隠すのはもっと難しくなり、利害関係者の関与に関してもっと軌道に乗っていただろう.
この特殊なケース（期限が短く、二度と使用されないコードがたくさんある）の場合、OOPコードにスクリプトエンジンを埋め込むことに注意することをお勧めします。
「都度リファクタリング」を学びましょう。主に「抽出方法」の観点から。シーケンシャル コードのブロックを書き始めたら、数秒かけて、このブロックを再利用可能なメソッドとしてスタンドアロンにできるかどうかを判断し、可能な場合はすぐにそのメソッドを作成します。使い捨てのプロジェクトでもお勧めします (特に、後で戻ってそのようなメソッドを個人用ツールボックス API にコンパイルできる場合)。ほとんど考えずにできるようになるまで、それほど時間はかかりません。
うまくいけば、あなたはすでにこれを行っており、私は合唱団に説教しています.