レガシーコードをC#で書き直すべきか？デレク・コマーティンの見解を深掘りする

"コードを書き換えない"原則

デレクは冒頭で、ソフトウェア開発でよく言われる長年の忠告を認めます：決してゼロからコードを書き直すべきではないこの感情は、Joel Spolsky氏による"Things You Should Never Do"と題された有名なブログ投稿に由来しており、レガシーシステムの書き換えを強く警告しています。

0:32で、デレクはスポルスキーの記事から最も重要なアイデアを指摘している：

"彼らは、ソフトウェア会社が犯しうる最悪の戦略的ミスを犯しました：コードをゼロから書き直すことにしたのです"。

デレクは、主なポイントは次のように説明する。"ゼロから始める場合、必ずしも最初にやったときよりも良い仕事ができると信じる理由はありません。特に大規模で複雑なシステムでは、現在の実装に埋もれている隠れた価値を過小評価しがちです。

単純さという幻想

1:07で、デレクはジュニア開発者としての日々を振り返っている。 他の多くの人と同じように、彼は単にコードが悪いと思ったので、システムの大部分を書き直したいと思うことがよくありました。 しかし彼は後に、このような思い込みは、コードそのものが本質的に劣っているのではなく、コードを理解していないことに起因していることが多いことに気づいた。

彼は親近感の持てる真実を語っています：

"ゼロから何かを新しく始めることは、コードベースやすべての複雑さ、エッジケースを掘り下げることよりも簡単です。

要するに、"タイヤの火"のように見えるものは、長年の進化とパッチに包まれた誤解された論理かもしれないのです。 開発者は、不慣れなことを悪いデザインと混同しがちです。

リライトが正当化されるかもしれない場合

それでもデレクは、リライトが常に悪いとは言わない。 1:44あたりから、彼はニュアンスを紹介し始める。 長年同じコードベースに慣れ親しみ、ドメインの複雑さやシステムの制限をすべて理解しているチームにとっては、リライトは有効な選択肢かもしれません。

"本当に長い間システムに携わっているのであれば... そこで、ニュアンスが重要になります。 そう、このツールはタイヤ火災のようなもので、私たちの足かせになっているのです。 リライトするのが適切かもしれません"。

"Worse Is Better"と80/20ルール

デレクは2:01から "Worse Is Better "の概念をパレートの原理（80/20の法則）と結びつけて紹介しています。 彼は、多くの場合、システムの価値の80％はコードベースのわずか20％から生まれると主張する。 そのため、リライトの際には、すべてを複製するのではなく、真に価値を提供する核心部分に焦点を当てることを目標にする必要があります。

"機能が少なければ少ないほど良いというわけではありません。

彼は、シンプルさと実用性は、多くの場合、完全性よりも優先されると説明しています。 レガシー・プラットフォームが広大でメンテナンスが困難であるよりも、限定的ではあるが使用可能でメンテナンス可能なシステムの方が、より良いサービスを提供できるかもしれません。

コストと利益の比較

2:47、デレクは、最終的な判断はしばしば費用対効果の分析に帰結すると示唆する。 リライトのためのリライトは決して正当化されません。 しかし、古いコードを維持するコストや、古い技術によって制限されるコストが、再構築よりも大きい場合、方程式は書き換えを支持する方向に変わるかもしれません。

彼は、時代遅れのプラットフォームやツールに固執しているために競争力が妨げられている状況について言及しています。 このような場合、技術的なギャップそのものが、再構築の正当な理由になります。

グレッグ・ヤングのレッスン

Derekは、3:12にGreg Youngによる素晴らしい投稿を持ち出した。この投稿では、誤って製品化されたプロトタイプが書き直されている。 リライトには9ヶ月を要しました。 結果は？

"9ヶ月間の美しいアーキテクチャとコード作業の後、私たちは月に約10,000ドル多く稼ぐことができました。

グレッグは、その1つを再構築するために深く投資するよりも、新しい戦略をテストするために30個の新しいプロトタイプを構築した方が良かったと結論づけた。 デレクがこの結論を気に入ったのは、技術的に完璧であることが常にゴールであるという前提に挑戦しているからです。

特に、すでにビジネス価値を提供している場合はなおさらです。

"古いか新しいか"のバイアス

4:20で、デレクは"古いものは悪く、新しいものは良い"という一般的な考え方を取り上げている。 彼は個人的な例として、同じ目的を果たす2つのサードパーティ・サービスと統合しています。 1つは最新のJSONを使用し、Pythonで構築されている可能性が高い。 もうひとつは、驚くことにXMLを返し、おそらく1990年代にColdFusionで作られたものだ。

"どちらも同等です。 安定しています。 これらのツールは、私と私の顧客に同じ価値を提供します"。

これは、新しいものが常に良いとは限らないことを強調しています。 安定性、信頼性、有用性は、多くの場合、技術スタックよりもはるかに重要です。

デレクの個人的なリライトの経験

デレクは5:31から、自身の体験談を披露する。彼は、元のシステムのドメインで6年以上過ごした後、大規模な書き換えに参加しました。 書き換えには約14カ月を要しましたが、その主な原因は、システムが最新のeコマース・ツールやオンライン・サービスと統合する能力を制限する技術的なギャップでした。

"この目的のために、本当に新しいものを作り直す必要がありました。

これは単に"コードが悪い"というだけの問題ではなく、システムが根本的に進化できないものであったため、再構築することが唯一の有効な道でした。

最終的な考え

ビデオの最後、6:11あたりでデレクは、答えは単に"イエス"でも"ノー"でもないことを強調しています。

"明確な答えがノーだとは思いません。なぜなら、文脈が重要であり、多くのニュアンスがあるからです"。

レガシーC#コードの書き換えが必要な場合もありますが、文脈、ドメイン知識、価値の提供、技術的制約のすべてがその決定をサポートする場合に限られます。

結論

Derek Comartin 氏の video は、ソフトウェア開発で最も議論されているトピックの 1 つについて、バランスの取れた、経験主導の見解を示しています：レガシー コードは書き直すべきか？ 彼のアドバイスは独断的ではなく、思慮深く、根拠があり、個人的な洞察に富んでいる。

Derekは、歴史的な教訓、現実世界の物語、そして"新しいことは良いことだ"という罠を振り返ることで、ソフトウェア・アーキテクチャにおける最も重大な決定の1つを行うための成熟したフレームワークを視聴者が開発できるようにします。

もしあなたがC#プロジェクトで同じような選択を迫られているなら、デレクのビデオを見直して、文脈をよく吟味してください。 レガシーコードが敵ではないこともあります。

デレクのYouTubeチャンネルで、より多くの洞察に満ちたビデオをご覧ください。 デレクの他のコンテンツは、CodeOpinion.comをご覧ください。