6

ソフトウェアを捨てるのはよくありませんか?
ジョエルは、企業は決してソフトウェアを捨てるべきではないと結論付けています。

私は良い小さなプログラマーになり、このルールに従うようにしています。私は、1 人の男性が運営する 5 年前のプロジェクトに参加しました。アンチパターンでいっぱいで、一般的に設計が貧弱です。問題のほとんどは、インライン動的 SQL を使用したデータ層に起因します。

  • 長所: ユーザーはこのアプリの動作に慣れており、バグにも慣れています。要件は構築されていますが、ユーザーがアプリケーションの全体的な信頼性に疑問を抱く原因となっている根本的な問題がいくつかあります。
  • 短所: アンチパターン、激しいカップリング、インライン SQL、不可能なデータ層。

要件を再収集し、オブジェクト指向、デザイン パターン、および最新の .NET 手法を使用してこのアプリを作成することができました。管理可能でチーム化可能。
小規模なアプリケーションで、このような問題がある場合、Joel のアドバイスに従うべきでしょうか?

この質問は主観的であるために投げ捨てられるかもしれませんが、これはプログラマーとしての私の仕事にとって非常に重要であることがわかりました.

4

8 に答える 8

11

ジョエルが言いたいのは、すべてを捨ててゼロから始めると、何年にもわたる作業を投げ捨てることになり、書き直しが既存のものよりも大幅に改善されるという保証がないということです。

書き直しに集中する代わりに、一度にアプリケーションの 1 つの部分をリファクタリングすることの実用性を検討してください。インライン SQL の代わりに、おそらく LINQ などの「より優れた」アプローチに基づいて、新しいデータ層を作成することを検討してください。次に、一度に 1 つの関数をその新しいレイヤーに移行できます。このようにして、何年にもわたる以前の作業を捨てることなく、より良いコード ベースの目標に向かって前進します。

于 2010-11-17T15:35:50.273 に答える
5

私のアドバイスはこれです。それが機能する場合は、アプリケーションの次の重要なリリースまで、いじらないでください。次に、必要に応じてリファクタリングします。私の会社でも同じ問題に直面しており、通常、私が説明した方法で問題に対処しています。

古いコード、悪いコード、またはもはや関連性のないコードを捨てないことは、IMO としてはばかげています。コードに、簡単に再現できない重要な要素が含まれていない限り。

于 2010-11-17T15:34:22.877 に答える
4

問題のほとんどは、インライン動的 SQL を使用したデータ層に起因します。

UI とデータの間に何らかの違いがある限り、これは必ずしも問題ではありません。インライン SQL を偏見しないでください。パラメーター化されている限り、完全に実行可能なアプローチです。

再質問; それを廃棄する技術的な理由は何なのか、私は疑問に思います。実質的に (理想的には $£€¥ で)正当化できる場合は、それで結構です。しかし、見た目が気に入らないという理由だけでそれをしないでください。以前にコードを破棄したことがありますが、回帰のない方法でそれを実行しようとすると、曲がりくねった作業になる可能性があります。

ユーザーに関しては。しかし、UI を変更したい場合でも、ほとんどの人は非常に柔軟で、新しい UI に喜んで適応します。

于 2010-11-17T15:36:33.613 に答える
3

すべてを捨ててゼロから始めるのではなく、ユニットテストでサポートされている小さな変更を加えながら、リファクタリングします。ゼロから書き直すコストは、ほとんど価値がありません。

于 2010-11-17T15:35:16.387 に答える
2

MichaelFeathersによるLegacyCodeを効果的に使用する方法を確認するための必須プラグを作成します。彼は、レガシーコードをテスト対象にすることに重点を置いて、段階的にリファクタリングすることを強く主張しています。この本は少し古くなっていますが、コードもそうです。いわゆる「ブラウンフィールド」プロジェクトへのアプローチ方法を変えた概念の転換を行うのに役立ったので、非常に役立つことがわかりました。開発者が家を改造するように頼まれた場合、彼はめったに構造をブルドーザーで覆い、最初からやり直すことを提案しません。プロジェクトは単純に高額になり、構造が使用できなくなる期間が長すぎます。

于 2010-11-17T15:54:27.080 に答える
1

これはまさに、古いバージョンを保持したい場合です ;)

古いシステムの正確なバグを備えた新しいシステムを複製するまで、ユーザーは古いアプリケーションを元に戻すように要求します...多くのユーザーは、いくつかのバグを機能として認識します (「クイック シャットダウン オプション」や、遭遇したあらゆる癖など)。

于 2010-11-17T15:43:24.363 に答える
1

あなたが説明したようなソフトウェアは厳密に破棄されるわけではないと思いますが、おそらく最初に一連のテストを作成してプロセス中に何も壊れないことを確認した後、すべての認識を超えてリファクタリングする必要があるかもしれません。

その時点で、それは捨てられましたか？はい、最終的な EXE 名と表示される操作は同じかもしれませんが。要するに、これは実際のベスト プラクティスよりも、セマンティクスの問題であり、現実世界の制約に直面した場合のプラグマティズムの問題である可能性があると思います。

于 2010-11-17T15:36:18.223 に答える
0

通常、顧客が製品に「満足」している場合、完全な書き直しをビジネス上正当化することは非常に困難です。私のアドバイスは、新しい機能を開発するときにリファクタリングして、目的のアーキテクチャにゆっくりと移行することです。これは、言うは易く行うは難しですが、あなたが説明したようなプロジェクトには意味があります。

于 2010-11-17T21:24:44.780 に答える