インターフェースの実装が新しく改善されたため、後方互換性をあきらめるのはいつですか?[閉まっている]


11

私は同じソフトウェア会社で10年以上働いています。その結果、さまざまなオブジェクト指向プログラミング言語を使用して大規模なコードベースを実装しました。私はキャリアを始めたばかりの初心者プログラマーであり、良いインターフェイスとクラス設計の原則についてはあまり知りませんでした。私の設計スキルは時間の経過とともに向上したと思いますが、下位互換性の問題のために、以前のコードを改善するのはますます困難になりました。私のコードは、私の会社が販売する製品の一部として多くの顧客に使用されています。

私の質問は次のとおりです。古いインターフェイスの後方互換性を維持しようとするのをやめ、真新しいデザインを実装するために弾丸を噛むのはいつですか?

後方互換性を維持することが非常に大きな負担になり、インターフェイスの便利な変更が不可能になるポイントが来ると思います。誰かが同様の懸念を経験しましたか?フィードバックを提供できる人はいますか?


3
I think there comes a point where keeping backward compatibility becomes such a big burden that useful changes to interfaces become impossible.-そして、私は...あなたがあなた自身の質問に答えだと思う
ヤニス

(1)これはコマーシャルですか?(2)インターフェイス/実装を使用するために、顧客は継続的にサポート料金を支払いますか?(一回払いバーサス)
rwong

私は、顧客が最初の購入とメンテナンスを継続したい場合に料金を支払う商用ソフトウェアに取り組んでいます。
カフカ

回答:


5

「いつ」というのは良い質問ですが、「どのように」がより関連性があると思います。ユーザーをイライラさせたり不満を抱かせたりしない方法で、重大な移行を行うことは困難です。考慮すべきいくつかの項目:

  • 移行のかなり前にクライアント/顧客と通信します。実装の理由と方法を説明します。セキュリティ、パフォーマンス、安定性、および将来の柔軟性を理由として挙げることはすべて有効です。
  • とにかくきれいな休憩をしているなら、フィードバックを求めてください。
  • サードパーティの開発者がいる場合は、意味のある限り多くのサードパーティの入力も含めるようにしてください。
  • 可能であれば、互換性レイヤーを提供します。
  • 包括的なアップグレードガイドを提供します。
  • アップグレードを可能な限り簡単かつ無痛にします。少し手間がかかる場合でも、ユーザーの痛みを最小限に抑えます。
  • 請求する場合、新しいバージョンへのアップグレードの割引を提供します。
  • アップグレードを奨励するために、少なくともいくつかの新しい有用な機能を新しいバージョンに追加します。これは、管理者にとってアップグレードをより魅力的にする上で特に重要です。
  • 休憩する場合は、最後に休憩を取る必要があります。つまり、事前に包括的な計画を立て、すべてが適切にセットアップされていることを確認します。
  • UIをお持ちの場合は、変更を簡単に行ってください。再設計するのではなく、リフレッシュすることを考えてください。技術に詳しくないユーザーにとって、あるバージョンから別のバージョンへのUIの大幅な変更は、フラストレーションの大きな原因になります。
  • 新しいバージョンは、古いバージョンよりも著しく安定しており、パフォーマンスが高いはずです。ユーザーにアップグレードを再送する理由を与えないでください。事前に広範なテスト(単体、統合、およびベータテスト)を行わずに新しいバージョンをリリースしないでください。
  • 古いバージョンを同時に長期間維持します。廃止してサポートを中止することにした場合は、少なくとも6〜12か月前に通知し、可能であればさらに通知してください。
  • 財務と人的資源の両方の面で、2つのバージョンを一度に維持する余裕はありますか?(また、ビジネスの観点からは、古いバージョンにしがみついていて、アップグレードしたくない残りのクライアントを失う余裕があるまで、古いバージョンのサポートを停止しないでください。それを維持することはあなたの利益を上回る。)
  • 必要に応じて、古いバージョンが廃止された後、一定期間セキュリティ更新を行うことを確約します。
  • 繰り返しになりますが、プロセス全体を通してコミュニケーションは膨大です。ユーザー/クライアント/顧客をいつでも見捨てられたままにしないでください。彼らの忠誠心と情熱はあなたのビジネスの基盤です。ブログまたはフォーラムで質問に必ず回答してください。社会的要因を過小評価すべきではありません。

「いつ」については、おそらく他の誰よりもあなたのアプリケーションに対してより良いアイデアを持っているでしょう。ただし、一般的に、技術的な負債とアーキテクチャが安定性を完全に阻害し、合理的なパフォーマンスを妨げ、新機能の開発を圧倒的または不必要に困難にするときは、すっきりと休憩するときです。

とは言っても、このステップを軽視しないでください。正しく行われたとしても、後方互換性を破ることは大したことです。ブレークを検討する前に、テストカバレッジの拡大とリファクタリングをまず検討し、可能な場合はできるだけ検討する必要があります。


1
+1:実用的なソリューション。結局のところ、質問は「後方互換性を維持することが非常に大きな負担になり、インターフェースの有用な変更が不可能になるポイントが来ると思う」ということは非常に明確でした。これが事実であるため、前進する方法に関する具体的なガイダンスでこれに対処することは理にかなっています。
S.Lott

2

一般的に、私はジェームス・アンダーソンに同意します。しかし、私の経験では、考慮が必要な追加の側面があり、進化するインターフェイスを実際に許可するオプションを指している場合があります。

この例は、私が作業しているチームの1つからのものです。彼らは定期的に製品を出荷します。少なくとも月に一度、時には毎週です。新しい機能と新しいプラットフォームは新しいバージョンでのみサポートされるため、お客様はアップグレードすることをお勧めします。アップグレードは簡単で、顧客は中間のバージョンをスキップすることもできます。ダウングレードはサポートされていません。さらに、バージョンは3年間のみサポートされます。その後、保守料金が2倍になる猶予期間が1年間あります。

その結果、大多数-顧客の約95%-が少なくとも年に1回は定期的にアップグレードしています。これは、新しいインターフェイスを徐々に導入できることも意味します。

古いインターフェースはどうですか?このチームが使用する手法は、古いインターフェースを「サポート終了」として宣言することです。その後、新しいインターフェイスが利用可能になり、古いインターフェイスがまだ廃止されていない12か月の期間があります。新しいインターフェイスは古いインターフェイスよりも優れた機能を提供するため、2つのインセンティブがあります。古いインターフェイスのサポート終了と新しいインターフェイスの改善です。

この場合の具体的な古いインターフェイスは、プラットフォーム固有のテクノロジーであり、標準的な主流のテクノロジーに基づいたサービスインターフェースに徐々に置き換えられつつあります。

もちろん、この変更は一晩では発生せず、完了するまでに何年もかかります。しかし、古いテクノロジーへの投資をやめ、代わりに新しいテクノロジーへの投資を許可しました。お客様には支援が提供され、今後の道が開けます。彼らのほとんどは、新しいテクノロジーへの動きも歓迎しています。

ただし、この特定のアプローチはシナリオでは機能しない可能性があることに注意してください。それは確かに私が一緒に働いているチームのために機能します。


1

あなたはすでにここでいくつかの良い答えを得ているので、このトピックに関するJoel Spolskyの非常に素晴らしい記事へのポインタを追加したいと思います。彼はIE 8の後方互換性を放棄する計画について議論しています。これはあなたの問題と本質的に同じです:

http://www.joelonsoftware.com/items/2008/03/17.html


1

簡単な答えはネバーです!

経験によれば、下位互換性の低下は、少なくとも顧客とユーザーを悩まし、さらに悪いことに、それらを完全に失います。

あなたがあなたとあなたのすべての子孫の慣習的な呪いを終えた後、ユーザーにコードを書き換えるように頼んでいる場合、彼らは「私が読んでいる素敵なACMEライブラリに切り替える必要があるかもしれませんそんなに?」

秘Theは、後方互換性を損なわないように現在のインターフェイスを強化するか、古いインターフェイスを維持しながら、まったく新しい光沢のある明らかに優れたインターフェイスを提供することです。ある時点で、新しいインターフェイスには古いインターフェイスでは不可能な機能が追加されますが、これにより、問題を強制することなく人々に動機を与えることができます。

これをさらに明確にするために編集します。

プログラマーとしてのあなたの考えは-

「私はこのAPIを改善し、システムを可能な限り改善し、誰もが私を賞賛します」。

APIのユーザーが考えることは-

「A * * * e彼は私の時間とスケジュールは重要ではないと考えている。私は自分のやっていることを止め、彼のエゴを満足させる以外の理由ですべてのコードをリファクタリングしなければならない。別のAPIに貼り付けて、彼にもそれを貼り付けます。」


1
「思考」を追加して、怒りの強制的な変更がいかに人々を作るかを強調しました
ジェームス・アンダーソン

1
決して?まあ。Microsoftは、Windowsの各メジャーリリースでこの原則に違反しているようです。実際には、「決して」は実際には従わないと思います。「まれに」、「慎重に」、「しぶしぶ」は「決して」よりもはるかに良い言葉のようです。質問には「後方互換性を維持することが非常に大きな負担になり、インターフェースの便利な変更が不可能になるポイントが来ると思う」とあります。この特定の問題に対処できますか?
S.Lott

@ S.Lott ネバーのような不必要に強力な言葉を使用するのは、典型的なJoel Spolsky効果であるということめったにないということです:)
maple_shaft

2
@ S.Lott:同じマイクロソフトについて話していますか?最新のOSを使用して、最初のOS用に作成されたほとんどのプログラムを実行できるMicrosoft。古いOSの不特定の動作に依存する人気のあるゲームが引き続き機能することを保証するために、新しいOSにコードを追加したMicrosoft
マイケルボルグワード

-1:一部のお客様は、価値があるよりも高価です。
ジムG.

0

これは実際には技術的な決定というよりもビジネス上の決定です。通常、これはメジャーリリースの一部として行われ(バージョン3.5からバージョン4.0への移行など)、多くの場合、2つのバージョンがしばらくの間並行してサポートされます。つまり、古いバージョンでメンテナンスを行いますが、すべての新機能は新しいバージョンでのみ表示されます。古いバージョンは、会社がそれから利益を得る限り、または少なくともメンテナンスコストを相殺するのに十分な限りサポートされます。これを経営陣に売り込む準備をしてください。


0

私はこの顧客の側にいたので、それは本当にあなたが移行に関して何を計画するかに依存すると言うでしょう。

現在、アカウントシステムをアップグレードしています。アップグレードを行っている会社は、以前の互換性のないバージョンもサポートしています。彼らは、データを取得して新しいシステムに移動し、(理論上)すべての古いデータがそこにあるようにします。データ変換には数百ポンドを支払います。問題ない。

私が働いていたanothe rcompanyの以前の状況と比較してください。サプライヤーには、古いシステムから新しいシステムに移行する方法がありませんでした。これにより、他のすべてのサプライヤーと同じ状況になります。実際、彼らは私たちがアップグレードを支援することを約束していないことを知っていたため、彼らの状況は悪化しました。彼らは新しい契約を取得しませんでした。

顧客の獲得と維持に苦労しましたが、どのように移行を容易にすることができますか?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.