ビジネスケースでレガシーソフトウェアの書き換え/改良を正当化する方法は？
私は、メインのソフトウェアパッケージから大きな収益を上げている素晴らしい小さなソフトウェア会社で働いています。私にとっての問題は、それがほとんど維持できないことです。これはDelphi 7で書かれており（バージョンは徐々にアップグレードされています）、過去20年ほどにわたって多くの開発者によって開発されてきました。
ソフトウェアには意味のあるアーキテクチャがありません。オブジェクト指向はまったくなく、恐ろしいほどの量の循環依存関係と、いくつか例を挙げるとグローバル変数に過度に依存しています。 Delphi 7は64ビットをサポートしていません。
ここでの問題は、私の管理チームは技術的なことを気にせず、なぜ気にかけるべきなのかを知りたいということです。明らかにそれは予想されることなので、ここで私が求めているのは、この種のことについてのガイダンス、物語、または落とし穴についてです。
私が含めたいことがいくつかあります。つまり、「レガシー」コードの機能のデバッグ/書き込みにかかる時間と、一貫性のある適切に構造化されたOOコード）です。これが話題になっているブログの投稿などを知っていますか？私たちにとって、これは大きな理由です。きちんとした開発者であるにもかかわらず、新しい機能を書くことは、より多くのゴミを積み上げているような気がします。コードをきちんと理解している私にとって、物事を変えることは腹立たしいことです-小さな変更はばかげたドミノ効果をもたらす可能性があります。
誰かが共有したい経験がありますか？
ソフトウェアは保守可能です。それがあなたがそれに取り組んでいる理由です。実際、そのソフトウェアの販売とサポートから得られる収益は、おそらくあなたのロードした給与をサポートしています。うまく機能するものを管理しているなら、それはそのままにしておきます。複雑な配管構造の家がある場合、現在は完璧に機能していますが、配管工にその建築物を掃除してもらうことはできますか？おそらく違います。
ソフトウェア開発者として、なぜあなたが優れたアーキテクチャ、オブジェクト指向などを求めているのか理解しているので、私やソフトウェア開発者を売る必要はありません。
ソフトウェア製品は「牛の牛」モードになっているに違いない。彼らは死ぬ前に既存の顧客からできるだけ多くの利益を得ようとしているだけです。それが真実ではない場合、パイプラインから降りてくる建築シナリオは何ですか？同じデータの詳細？新しいデータ？プラットフォームまたはツールの廃止高性能アルゴリズム？顧客基盤の拡大？新機能？新しいプラットフォーム？モバイル？アーキテクチャを変えるきっかけとなる新しいビジネス条件がない場合、アーキテクチャは変化しませんか？あなたの建築が次の変更が信じられないほど高額な修正を引き起こす臨界点にあるなら、彼らが変更にお金を払う用意がある前にそれが起こるのを待たなければならないでしょう。
このギグの利点は、Delphiのスキルを見つけるのが比較的難しいため、おそらくあなたを解雇できないことです。そして、あなたが収益性の高い製品をサポートしているとき、雇用保障があります。
ソフトウェアに関するジョエル-してはいけないこと、パートI を読んでください。鉱山は明らかにそれを読んでいませんでした、もし彼らが読んだとしても、彼らがもっと早く読んだことを願っています...
Java 100万行を超えるレガシーADAコードベースから書き直されたプロジェクトに取り組んでいます。現在、100万行未満の新しい「Java構文」レガシーAdaプログラムがあり、以前は存在しなかった欠陥、およびほとんどの場合、この種の作業を行う多くの新機能。幸いにも、ユニットテストフレームワークがあり、欠陥が見つかったときに、失敗した別のユニットテストを記述して、欠陥を修正できます。そのユニットが通過し、他のダースが失敗するのを見てください......
本質的に、愚かな者だけが新しいコードベースの空の約束のために動作しているコードを引き抜くでしょう。
うまくいった私の経験の1つ
システムは死んでいて、市場の変化に対応できず、顧客に直面し、古い方法で外観や作業が行われ、バグレポートが非常に多かったため、修正にかかる推定時間はすべてを書き直すだけではありませんでした。いくつかのレッスン
- 時間の見積もりは間違っていましたが、
- 新しいシステムには新しい/より良い機能がありました
- 機能を追加するのは本当に簡単でした
- バグが発生したとき、それは主に1時間以内に修正されました
- デザイナーがデザインを更新する機会があったため、ユーザーエクスペリエンスが大幅に強化されました。
あまり良くない経験
システムは非常にバグが多く、恐ろしいデータモデルとデータアクセス層がありました。実際にそれを妨げていたのは、使用されたテクノロジーでした。現在のデータモデルの使用について議論がありましたが、放棄されました。新しい機能を可能にするには、新しいデザインが必要でした。
- 最初のシステムからの問題が光りました。物事がめちゃくちゃだった理由は、彼らが何を望んでいるのかはっきりしない力があったからです。
- 絶え間ない心変わりから生じる大きな遅れがプロジェクトを殺しました。
- ソフトウェア自体はなかなか上手く動いていましたが、皆さんの全体的な気持ちは良くありませんでした。
リファクタリングの成功
私はいくつかのシステムを手渡されましたが、一部のシステムは書き換えが正当化されます（一部の人々は非常に熱心で、コードが異なるために単にそれを実行したい場合もあります）。
特定のシステムは混乱していた。レイヤーはすべて区別できないデータアクセスレイヤーと混同され、画面上のコントロールはButton1、Button2 ...という名前が付けられました。変数が再利用され、コードの一部がさまざまなクラスにコピーされました。
リファクタリングツールの使用は非常に役立ちましたが、本質的には約2か月の専用作業が必要で、バグ修正や機能強化のリクエストが散在していました。基本的に、プロジェクトは大規模な内部の見直しにもかかわらず、実行し続けることができます。小さなものから始めて、すぐに細かいことを修正すると、何かで快適に作業できることがわかります。
私が学んだレッスン
常に書き直さない理由はすべて考えてくださいを試してください。死にかけているシステムをどのように救うことができるか、できる限り考えてください。思ったより作業量が少ないことに驚かれるでしょう。書き換えは大規模なギャンブルであり、良い会社ではうまく機能します。管理は通常、新しいバージョンに機能を追加することにより、書き換えを正当化しようとします。これは、絶え間ない範囲のクリープ、愚かな機能x、分析麻痺、および新しいプロジェクトに伴うその他すべての悪いことの悪夢を開く可能性があります。
あなたの会社が新しいプロジェクトに長けており、それを保存する方法がない場合は、システムの何が悪いかについて報告してください。あなたのマネージャーにそれを見せて、別の開発者から第三の意見を得て、そこからそれを取ってください。
ビジネス志向の人々に関してはいつものように、あなたのケースを損益分析として提示してください。あなたの分析はこれらの3つの質問に答えるべきです：
- 提案された再構築によって、どのような追加の収益を生み出すことができますか？ （たとえば、64ビットのサポートは、よりターゲットを絞ったプラットフォームに変換できます）
- 再構築によってどのような収益損失が抑制されますか？ （例：メンテナンスに費やす時間とリソースを減らし、新機能を追加する）
- your再構築のコストは、上記の2つの項目を十分に変更することで正当化されますか？
この図は、アプリケーションのコードベースの品質とビジネス価値の関数です。
このグラフは、レガシーソフトウェアのリエンジニアリングが正当化される時期と正当化されない時期を示すガイドのふりをしています。たとえば、ソフトウェアのビジネス価値が高く、コードの品質が低い場合、リエンジニアリングは正当化されます。
現在持っているソフトウェアとまったく同じことをするソフトウェアに大量のお金を費やしてビジネスケースを作るにはどうすればよいでしょうか。また、まったく同じことをしないという追加のリスクはありますか。
幸運を。
これが話されているブログの投稿などを誰か知っていますか？
はい、確認して経営陣に転送する必要がある2つの記事を次に示します。
次に、レガシーソフトウェアについて注意すべき点を2つ示します。
変更が難しいレガシーソフトウェアは次のようになります。
- 会社の将来の選択肢を制限します（会社が現金牛を搾乳するだけではない場合）。
- 現在の開発者を失望させ、新しい才能を引き付けて維持する会社の能力に影響を与えます。
現在のプロジェクトに存在する問題に対処できない理由はありません。赤ちゃんをお風呂の水で捨てる必要はありません。存在する問題に対処する方法はたくさんあります。高レベルの欠陥がある場合、単体テストと検証および検証テストはそれらのソリューションの1つです。
ソフトウェアには意味のあるアーキテクチャがありません。オブジェクト指向はまったくなく、恐ろしい量の循環依存関係と、いくつか例を挙げるとグローバル変数に過度に依存しています。 Delphi 7は64ビットをサポートしていません。
Delphiは、JavaおよびC＃をサポートするほぼすべての最新のプログラミング概念をサポートしています。これは、循環依存関係とグローバル変数の問題を簡単に解決できることを意味します。必要に応じて、オブジェクトの向きを解決することもできます。一度に1つの問題に対処する必要があります。
ここでの問題は、私の管理チームは技術的なことを気にせず、なぜ気にかけるべきなのかを知りたいということです。明らかにそれは予想されることなので、ここで私が求めているのは、この種のことについてのガイダンス、物語、または落とし穴についてです。
あなたは彼らの従業員として、ソフトウェアが保守不可能であると信じています。あなたは理由のために主張をする必要があります、あなたはプロジェクトが維持できない理由の解決策を考え出す必要があります。これを実行できない場合は、20年以上維持されているため、プロジェクトIS ACTUALLY MAINTAINABLEが考えられます。