6

私は、大規模なリファクタリングまたは完全な再設計を含むプロジェクトの保守計画に関与しています。5 年間にわたって有機的に進化してきた非常に複雑な既存のテクノロジー スタックがあります。私自身、3年前に入会し、狂気に「巻き込まれ」ました。このスタックは、クライアントの進化するニーズに基づいてまとめられたものであり、多くのテクノロジーと制御不能なデータのコレクションで構成される管理不能な巨大なものになりつつあります。

私たちの主な目標は、スタックをより実行可能で管理しやすくし、将来的にデータを管理するためのより良いシステムを考え出すことです。主に PHP で書かれた緊密に統合されたビジネス モデルと REST コントローラー システムを、一貫性のある REST API に変換したいと考えています。

当社の PHP ビジネス モデルは、ほとんどのデータを含む eXist XML データベースと、2 つのサブアプリケーションのデータをサポートする MySQL に依存しています。データ ストア内のデータを動的に管理するための SQL および XQuery ソース コードのライブラリがあります。PHP-Java Bridge と SAXON および FOP を使用して Java コードに依存し、XML データベースに保管された文書の PDF 複製を作成するビジネス・モデルの部分もあります。これは Web アプリケーションであるため、PHPTAL、XSLT、CSS、XHTML、および JavaScript の組み合わせを使用して、クライアント UI を容易にします。最後に、Ant タスクを使用して管理される PHP、Apache、Perl で記述された関数を管理する一連のハウスキーピング スクリプトがあります。

スタックの基本的な機能は、さまざまなユーザー モデルの電子フォームを容易にすることです。アプリケーションの背後にある単純な哲学は、クライアントのいじくり回し、過度のエンドユーザーの手を握る行為、システム分析の監督の欠如、不適切なテスト方法論、将来の目標と明確に定義されたプロジェクト範囲の欠如の組み合わせによって、長年にわたって損なわれてきました。

現在、これ以上の開発を停止し、より良い単体テスト計画を含む場合と含まない場合があるシステムをより適切に説明し、同じテクノロジ コンポーネントを使用して API の基盤を作成することを計画しています。私の直観的な反応は、確かなスコープを考え出し、Web API の記述に適した十分にサポートされたプログラミング言語とフレームワークを使用してシステムを再設計することです。おそらくいくつかの機能が失われますが、最も重要な機能は保持されます。また、既存のデータを別の「読み取り専用」プラットフォームに移行することをお勧めします。

同様の状況にあった人への私の質問は次のとおりです。

  • どうやってこのような状況から抜け出したのですか？
  • この種の状況では、どのような計画手順を採用すると役立つでしょうか?
  • このような種類のスタックのソース コード管理手法はありますか? 私は何を探しますか？- 検索キーワード

完璧な解決策はないことを認識しており、これらの質問に答えるには、プロジェクトの問題をさらに詳しく説明する必要があります。いろいろな理由で、私は本当にそれをすることができません。この問題に対処するのに役立つリソースを見つけるのに問題があります。続行する方法についてアドバイスをいただければ幸いです。

4

1 に答える 1

2

もし私があなたの立場だったら、私が尋ねたり考えたりするであろういくつかの質問があります：

データベース設計:

  • どのような情報を取得する必要がありますか?
  • すべてをどのように結び付ける必要がありますか?
  • どのようなレポートを作成する必要がありますか?
  • どのような指標を収集しますか?
  • 古いデータを長期アーカイブ用に完全に消去する必要があるのはいつですか?

アプリケーションの設計:

  • クライアントが「ハンドヘルド」を必要とする可能性を低くするために、現在システムにどのような設計を施すことができますか?
  • 現在欠落または不足している機能は何ですか?
  • 顧客ベースを拡大するためにできる簡単な変更はありますか?
  • 正式なコーディング標準はありますか? 施行されていますか？
  • どのような種類のテストを要求しますか? (単体テスト、正式なQAなど)
  • どのような書類を要求しますか? (ソースコード、エンドユーザーなど)
  • アプリケーションの動作状況を判断するために、どのような指標を使用していますか?
  • 開始から 3 年間を振り返って、今知っていることを踏まえて、当時実装したいと思っていた設計上の決定は何ですか?

ソフトウェア：

  • より小さな技術セットを使用して、同じレベルで同じサービスを提供することは可能ですか?
  • 既存のスタッフが最もよく知っているテクノロジは何ですか?
  • より多くの人を雇う必要がある場合、正社員またはコンサルタントとして採用するのが最も簡単なテクノロジーは何ですか?

ハードウェア:

  • 既存のハードウェアはニーズを満たしていますか? そうでない場合、何が必要ですか？サーバーを追加しますか? より大きなサーバー？ロードバランサー? 等
  • 現在、仮想化を利用していますか?

人員:

  • すべての利害関係者から「賛同」を得ていますか? すべてではないにしても、少なくとも意思決定者から賛同を得ていますか?
  • 利害関係者は、これがどれほど大きな事業になるかを理解していますか?

防災・復興：

  • プライマリ サーバー/ネットワークが利用できなくなった場合、どのように冗長性を提供しますか?
  • どのようにデータをバックアップしますか (オンサイト、オフサイト、短期、長期)?
  • どのような種類の監視を設定する必要がありますか? 問題が発生した場合、どのように通知する必要がありますか? 誰に通知する必要がありますか?

申し訳ありませんが、コメントにそれを収めることができませんでした:-)そして、私はそれについて詳しく説明する時間がありません.会議を待っている時間をつぶしていました.

于 2013-01-31T21:36:51.643 に答える