ソフトウェアを保守不可能にするC#のよくある5つの間違い - デレク・コマーティンが解説

1.状態に対する所有権の欠如1.

デレクはまず、複数のバウンダリーやサービスが明確な所有権を持たずに共有データを更新できるようにすることの間違いを指摘する。彼は、課金システムがアプリケーションの別の部分に到達して状態を変更する例を使う。 これは、特にオブジェクトがシステム内の異なる場所に存在する場合に、データの一貫性の問題につながります。

このような自由奔放なアプローチでは、開発者が "なぜこのデータは間違っているのか？""誰が変更したのか？"と質問するようなエラーが発生します。デレクは、オーナーシップを定義しなければならないと強調する。システムの各部分は、明確に定義されたAPIやメソッドを公開すべきです。

アプリケーションのどの部分でも共有データを変更できるようにする代わりに、デレクは明示的なコマンドとクエリを作成することを提案しています。 例えば、出荷を更新したい場合、専用のインターフェイスからコマンドを発行します。 これは、構造を提供し、追跡不可能な変更によるリソースリークを回避します。

2.暗黙的なコードと明示的なワークフローの比較

デレクによると、多くのシステムはCRUD操作（Create、Read、Update、Delete）に大きく依存しているが、これは暗黙のワークフローを生む。 コードは技術的に機能的ですが、何をするのかが明確ではありません。 クラスが一般的な操作しかサポートしていない場合、実際のビジネス・ワークフローは隠されてしまいます。

ドライバーが荷物を受け取り、船荷証券が作成されます。 システムがUpdateShipmentを実行しただけでは、（BOL番号のような）文字列の変更がピックアップによるものなのか修正によるものなのか不明です。 Derekは、曖昧な更新をPickupStopLoadedのような明示的な操作に置き換えるべきだと指摘しています。

これは、より読みやすいコードにつながります。 また、例外が発生した場合、スタックトレースでどの操作が失敗したかを明確に示すことができるため、例外処理にも役立ちます。 明示的なメソッドは、各関数が単一の責任を持つため、より良いコーディング標準もサポートします。

3.無駄な指示の追加

デレクは、インダイレクト（呼び出し側とターゲット・メソッドの間に不要なレイヤーを挿入すること）について説明します。 彼はこれをデータベース接続で説明している。 コントローラはサービスを呼び出し、ヘルパーを呼び出し、ヘルパーは別のサービスを呼び出し、最終的にEntity Frameworkを介してクエリを実行します。

このような抽象化されたピラミッドは、問題の追跡やパフォーマンスの向上を困難にします。 より良いリソース管理のためにIDisposableインターフェイスをラップするなど、抽象化を作成することは有用ですが、Derekはそれをやり過ぎないように警告しています。 あなたの抽象化がAPIを簡素化するのか、それとも1か所にしか存在しないサードパーティの依存関係を隠しているだけなのか、自問してみてください。

レイヤーのためにレイヤーを重ねるのではなく、デレクはカップリングを直接管理することを提案する。 過剰な間接処理はコードを乱雑にするだけでなく、メモリリークの可能性を高め、ガベージコレクションの利点を弱めます。

4.What-Ifゲームをする

デレクが次に指摘する間違いは、決して起こらないかもしれない仮想的なユースケースを準備することである。多くのC#開発者は、将来のニーズを考慮して柔軟なクラスや関数を書いている。 例えば"2つの言語をサポートする必要がある場合はどうすればよいですか？" "技術を切り替える必要がある場合はどうすればよいですか？"

デレクは、このような考え方は、肥大化したフレームワークや過度に汎用的なコードにつながると警告する。 彼は、文字列連結ロジックや参照型ラッパーに遭遇することについて言及している。

未知のものに備えるのではなく、実際の要件に集中するようデレクはアドバイスする。 各メソッドと変数は、現在の正当な目的を果たすものでなければなりません。 未使用の機能は、メンテナンスコストを増加させるだけです。デレクが言うように、それは開発時間だけでなく、所有コストなのです。例えば、あなたのpublic bool Equalsの実装が、あなたが想像しうるすべてのエッジケースをカバーしているとしたら、しかし実際に起こることはない。

5.ワークフローを正しく管理していない

最後にデレクは、ワークフローをモジュール化されたステップではなく、手続き的なブロックとして扱うことの間違いについて議論する。 彼は実際の例として、オンライン注文を挙げています。ユーザーがチェックアウトを完了すると、システムはクレジットカードに課金し、確認メールを送信します。

例えば、支払いプロセスなど、あるステップが失敗した場合、コードはどのように反応しますか？ 注文を取り消しますか？ エラーを表示しますか？ 失敗メールを送信しますか？ デレクは、これを1つのブロックにまとめると、手に負えない複雑さが生まれると説明する。

彼は、ワークフローを、メッセージングを通じて通信する、小さく分離されたユニットとして設計することを推奨しています。 非同期タスク操作とyield returnを使用することで、これらのステップの管理が容易になります。 さらに、ファイルアクセスやデータベース接続のような外部リソースを囲むusing文とusingブロックを採用することで、メモリリークを防ぐことができます。

例えば、ストリームを囲むusingブロックは、ストリームが正しく廃棄されることを保証します。 ワークフローが複雑化した場合、これらのベストプラクティスによって例外を確実に捕捉し、効果的に処理することで、パフォーマンスと保守性を維持します。

まとめる：クリーンで保守可能なコードを書く

デレクは、動画の12:45で締めくくっているように、これらの間違いを、彼が見てきたこととしてだけでなく、大規模なビジネス・システムを構築している間に個人的に犯したこととしても振り返っています。 これらは経験を通じて学んだ教訓であり、彼は視聴者が自分の間違いをコメントで共有することを奨励している。

デレクのアドバイスは、C#だけでなく、他の多くの言語にも当てはまります。 文字列比較、Equals() メソッド、または新機能の設計のいずれであっても、重要なのは明確さ、意図、そしてコードの保守性を維持することです。

C#のスキルを向上させ、これらの一般的な落とし穴を避けることに興味がある場合、デレクのチャンネルは、システムアーキテクチャ、デザインパターン、実際のプログラミング言語に関するアドバイスに関する多くの無料リソースを提供しています。これらの間違いを1つでも避けることで、プロジェクトの質を大幅に向上させることができます。

今度コードを書き始めるときは、デレクの言葉を思い出して、"必要以上に複雑にしていないか？"と問いかけてみてください。

このようなコンテンツについては、デレク・マーティンのCodeOpinion YouTubeチャンネルをご覧ください。