他の3つのチームの後、継承されたプロジェクトの問題に対処する方法

この記事は普遍的なレシピであると主張しているわけではありません。他の3つのチームの後に得たプロジェクトで遭遇した問題とその解決策を説明しようとします。

最初に、プロジェクトの本質を簡単に説明します。 クリニックには、患者と彼の特別なデバイスへの訪問に関する情報を指示する医師がいます。 次に、この情報がテキスト形式に変換され（特別なユニットがこれを担当し、その従業員が聞き取り、入力します）、テキストがチェックされ、テンプレートが完成します。 次に、異なるビジネスロジックを持つさまざまな段階を含むワークフローに沿った動きがあり、その後、いくつかの外部システムとの統合が行われます。 そして最後に、患者に手紙が印刷されて送信されます。 作業はしばらくしてからアーカイブされます（ただし、必要に応じて同時に復元できます）。


同時に、ワークフローの一部はiPadで実行できます。システム設定とワークフローのための特別な部分があり、ブラウザーでドキュメントを編集および承認するための特別な部分もあります。 ただし、作業の大部分は、病院にあるユーザーのローカルマシンで行われます。

データが失われないという前提条件もあります。 したがって、ユーザーのローカルマシンでは、すべてがMySQLデータベースに保存され、そこからデータがメインサーバーと同期されます。

このプロジェクトの詳細は、西ヨーロッパのある国の医療分野です。 また、このソフトウェアパッケージは10を超えるクリニックに展開されており、各クリニックには固有の特性があります。 また、クリニックを新しいバージョンに誘導するには、多くの時間が必要です。最初にクリニックをテストサーバーに展開し、次に3週間テストし、次にライブサーバーに展開する必要があります。
データベースには患者に関する機密情報も含まれているため、各診療所には独自のサーバーがあります（実際に示されているように、新しいネジを購入するように説得することはすでに問題です）。

何を得たの？
ご存知のように、以前の3チームは質の高い仕事のために見捨てられませんでした。 C＃に約400,000行のソースコードがありました（さらにいくつかの外部ライブラリ）。 ソースコードの一部が失われました。 ドキュメントの欠如。 テストの欠如。 テストデータの不足。 システムに関するすべてを知っている人（プロジェクトが作成されてからの人）がいません。 コードは、ユニットをテストでカバーすることが不可能になるように作成されました。 約120のテーブルのデータベース、パフォーマンスの問題、ADO.NET、Dapper、LINQ、Entity Framework 4を使用してデータベースと対話します。 MS SQLデータベース。

アプリケーションアーキテクチャの一部：



描かれているシステムの部分についての簡単な説明：

• デスクトップクライアント-システムのほとんどの機能が実行されます-これは医師の作業用アプリケーションです
• デスクトップクライアントサービス-すべてのデスクトップクライアントが使用するサービス。
• タスクスケジューラ-作業を次のステージおよびその他の定期的な操作に転送するシステムモジュール
• iPad App iOS-iPadの医師向けアプリ
• Web管理者-作業プロセス、デバイスへのアクセス権などを設定するためのWebパーツ
• Webクライアント-医師向けのWebパーツ。使用可能な機能のリストはかなり限られています

いくつかの数字：
1週間（1年半前）に、合計5,000件の作品が処理されました。 作業処理とは、必要なすべての段階を経ること、すべての外部サービスと対話することなどを指します。

私たちには今何がありますか（1.5年の主な成果）？
一部の操作でのアプリケーションのパフォーマンスが10〜12倍になり、同時ユーザー数が5倍になり、1週間あたりの処理作業数が30,000に達し、顧客は落ち着きました
そして、私たちが遭遇した問題のいくつか（およびそれらを克服するために何をしたか）を説明します。

1つの問題：すべてが悪いことを顧客に証明する方法は？

ご理解のとおり、顧客はプログラムが機能していること、タスクを処理できることを確認しています。 そして、このシステムの「ボンネットの下」がすべてが松葉杖で機能すること、または限界で機能することを証明することは問題です。 関連する問題：システムが改善されていることを顧客にどのように示すか？

最終的に選択されるオプションの1つは、NDependシステムの使用です。 これは静的コード分析システムです。 そして非常に良い。 私が彼女について特に気に入ったのは、約150の標準ルールの存在です。

これらのうち非常に有用なのは、デッドコードを見つけるためのルールであり、未使用のクラスとメソッドです。 90％のケースで、それらは真実でしたが、間違いがありました。 彼らは、デフォルトのコンストラクタは使用されず、暗黙の変換演算子は必要ないと述べました。 実際、それらは必要でした。

作業のスピードも好印象を残しました-結果の40のライブラリーの分析には4-6秒かかりました。 また、継続的インテグレーションとの統合の容易さ（これはほとんど驚くことではありませんが）。 NDependが作成できる依存関係グラフはまだ有用でした。 これが顧客に示されたとき、これは機能の1つを実装するのにかかった時間の非常に良い正当化でした。

NDependのもう1つの興味深い機能は、コード分析のための独自のルールの作成です。 個人的には有用ではありませんでしたが、十分な標準ルールがあります。 同時に、プロジェクトが継承されたという事実のために、標準ルールを変更して（それらが合格するように）クリティカルにしました（違反した場合、Continious Integrationがメッセージを表示します）。 そして、コードの「品質」のしきい値が徐々に引き上げられました。

別の非常に便利な機能は、以前の分析結果との比較と違いの発見です。
この問題に関してどのような結論が導き出されたか：NDependは非常に優れた機能を持ち、多くの美しいグラフを構築し、拡張します。 顧客がグラフを見始めた後、彼はより穏やかになりました：彼は進歩を見ました。

2問題：データのプライバシー。

診療所は実際の患者と連携し、患者に関するデータは機密です。 さらに、それらは診療所のサーバー上にあります。 このデータには、医師の口述を含む音声ファイル、公式文書などが含まれていました。

より良いテストのために、このデータベースのコピーが必要でした。 しかし、機密データのため、病院はこのデータを提供することに熱心ではありませんでした。

したがって、ドキュメント内のすべての文字を単位に置き換え、すべてのオーディオコンテンツをゼロの配列に置き換え、すべての名前をName 1、Name 2などに置き換える匿名化プログラムが作成されました。
このプログラムの実装には約3日かかりました。 その後、ライブデータベースのコピーが作成され、匿名化されました。

間違いは何でしたか？ 彼らはそれが長くなることを考慮していませんでした（判明したように、匿名化の純粋な時間は約5日でした）。 匿名化が追加されました。 ライブデータベースが存在するのと同じ物理ディスクにロードすると、問題が発生します。 幸いなことに、念のため、ディスクから読み取るための大きなキューの最初の兆候を受信したら、匿名化プログラムを停止しました。

その後、中断後にデータベースの匿名化を続行し、夜間のみに実行を開始できるように、機能を追加しました。

この問題に関してどのような結論が引き出されたか：機密データは非常に大きな問題です。 さらなる使用が示すように、そのようなソリューションの利点はそれほど大きくはありませんでした。病院ごとに異なるビジネスプロセスがあり、データ構造が非常に異なっていたためです。 間違いなく、匿名化されたデータベースの使用は、それが実際のデータのコピーであることを理解し、これが新しいモジュールが実際のデータで予測可能な速度で機能することの良い証拠であったため、短期的な利点をもたらし、顧客を部分的に安心させました。

3問題：テスト用に作成されていないコード。

破壊せずに拡張する必要がある継承コード？ 単体テストを使用して生活を楽しむ方が簡単に思えます。 ただし、レガシーコードの品質は非常に悪かった。 そして、実践が示しているように、このコードはテスト用に作成されていません（テストに適さない古いEntity Frameworkを使用したシングルトン）。 しかし同時に、彼のためにテストを作成する必要がありました。 そして、統合テストを作成する方法を選択しました。 そして、ユニットテストでカバーできるように、新しい機能を記述しようとしました。

統合テストを作成するために、追加のテストを作成しました。 ユーティリティおよびデータベース回復機能。 T.O. プログラマーは、テストするアクションの前にプログラムを持ち込んでから、データストレージユーティリティを実行する必要がありました。 そして、テストの開始時に、復元されたデータへのパスを使用してデータベースの復元を呼び出します。 データストレージユーティリティは、データベースにあるすべてのテーブルを単純に調べ、それらのデータをXMLで保存しました。 その後、復元機能は動的に新しいデータベースを作成し、その中のデータを復元し、テストでこの新しいデータベースが見えるように接続線を変更しました。 データ回復のために、挿入コマンドの形成とADO.NETの使用を使用してコマンドを実行しました。これにより、Entity Frameworkなどからの独立性が得られました。 良い結果として-このユーティリティは他の言語に簡単に移行できます。

実践が示しているように、データベースを正しく準備すると、復元には1秒かかります。 CIで毎晩テストが行​​われていることを考えると、これは許容値でした。

そして、このユーティリティは、Ranorexを使用してテストを開始したときにテスターの間でも定着しました。コマンドライン引数を追加し、データベースの復元にも使用し始めました。

この問題に関してどのような結論を導き出しましたか：

1. レガシーコードの場合、小さな自転車を発明することはほとんど避けられません。
2. 統合テストについて考えただけであれば、すぐに夜間テストについて考えてください。
3. データベースの復旧は実際には非常に便利です
4. データベースをテストプロジェクトに復元するためにデータを保存する必要はありません。ドロップボックスのzipアーカイブにそれらをスローし、アーカイブへのリンクを保持することをお勧めします
5. 復元のプラスの副作用は、データベース構造の変更の正確性を確認することでした。これは定期的に行う必要があります。

問題4：ターゲットマシンのパフォーマンスカウンター。

また、関連するのは、1年の間に生じた質問です。継承されたシステムの状態をどのように表示し、徐々に負荷に耐え始めているのでしょうか。 最も効果的な方法の1つは、週ごとにパフォーマンスカウンターを収集することです。 本当に多くのカウンターがあり、優れたグラフを提供し、Excelにエクスポート、分析などができます。 残念なことに、週に5,000件の仕事があった当初からこれを行わなかったことが残念です。

また、このアプローチの利点は、これを行うように顧客を説得するのが非常に簡単であることです。これはWindowsの組み込み機能であるため、統計の収集を開始するように人々を説得する必要はほとんどありませんでした。

どのような結論を導き出しましたか？プロジェクトの最初にパフォーマンスカウンターを削除する必要がありました。 今では1ヶ月の間隔でそれらを比較することは非常に興味深いです。

5問題：RFHからHTMLへのコンバーターを信頼しないでください。

レガシーコードでは、ドキュメントはRTF形式で保存されていました。 顧客は、Webクライアントでドキュメントを編集する機能を完成させるように依頼しました。 顧客にはTxTextControl v 19のライセンスがあったため、エディターはこのコンポーネントを使用して実装されました。 ただし、書式設定（RTFからHTMLへ、またはその逆への変換が必要）が問題につながることが後に明らかになりました。 変換後に10番目のフォントサイズが10.5になることもあれば、他の多くの小さなkosyachokになることもあります。 この場合、それらのサービス。 サポートは、バージョン20へのアップグレードを推奨しています。 しかし、より詳細な調査を行った結果、20番目のバージョンには、私たちには適さない他の妨害が存在することが判明しました。

この問題についての結論：

• Webエディターのライセンスを持っていることを期待しないでください。 サポートはすべての問題を解決します。
• rtfをHTMLに変換したり、その逆を変換したりすると、多くの問題が発生しました。

6問題：iOSの失われた部分の回復。

Webパーツに加えて、iPadでアプリケーションを使用するための詳細なパーツもあります。 結局のところ、彼女からのソースコードは失われました。 いくつかの検索の後、逆コンパイルを使用してソースコードを復元しようとしました（これは、Ants Profilerを含むRedGate Developer Bundleを使用して実行できます）。 一般に、逆コンパイルの品質は非常に良好です。分析後、WCFサーバーでのIOSの認証が2時間以内にどのように行われたかを確認し、プログラムの最新バージョンで復元することができました。

結論：RedGate Developer Bundleは、そのような状況で私たちを本当に助けてくれました。

7問題-プロファイラー。

また、1つのパフォーマンスの問題が発生しました。クライアントで40分間作業した後、印刷の遅延が始まりました。 サーバーの観点から可能なことはすべてチェックしましたが、悪いことは何も見つかりませんでした。
幸いなことに、その時点でAnts Profilerを試してみることにしました。 非常に優れた利点があります-本当に使いやすいですが、ローカルマシンにインストールするためには管理者権限が必要です。 その下でプログラムを実行します-文字通り3クリックでのアクション。 もう1つの試用版は、14日間のフル機能期間です。最終マシンで1回実行する必要がある場合は、これが最適な選択です。
クライアントがプロファイラーの下で40分間起動された後、問題を見つけるために3分間であることが判明しました（ある場所では略語のリストが蓄積され、文字が入力されるたびに略語チェックが実行され、遅延が発生しました）。

もう1つの利点は、非常に優れたレポートです。これは非常に視覚的であり（レポートの例を以下に示します）、SQLクエリ、ディスクアクセス、ネットワーククエリをログに記録できます。

マイナス-最高レベルのプロファイリング詳細では、COMオブジェクトでは（少なくとも）うまく機能しません。 しかし、いくつかの実験の後、手順レベルでの詳細化は何も変わらないことがわかり、1年以上にわたってこの優れたツールを使用しています。

8問題-スナップショットレベルでのデータベースパフォーマンス。

すでに述べたように、私たちはヘルスケアで働いているという事実のために、更新にはかなり長いプロセスがあります。 約6か月前、ジョブ数が1週間あたり20,000ジョブに増加したとき、システムがタスクキューを処理できず、ユーザーの観点から作業ワークフローを通過しなかったため、顧客に問題が発生しました。 この問題は、テーブルからの読み取り中にブロックされたために発生しました。したがって、テーブル更新コマンドは、必要な速度で実行されませんでした。

したがって、サーバー上のアプリケーションを変更せずにアプリケーションを最適化するという課題がありました。
コードを変更せずに最適化する必要がある場合は、アプリケーションではなくデータベースを最適化する必要があると仮定するのは論理的です。 さらに、データベース内のインデックスはすでに作成されています。

1週間の分析の後、データベースをスナップショットモードに移行することにしました。 予想外に、これは異常に良い結果をもたらしました-400の仕事からのラインは12の仕事に減りました（しかし、これはすでに正常範囲内でした）。

この問題についての結論：インデックスの作成に加えて、MS SQLで利用可能なメカニズムを忘れてはなりません

9問題-レポート。

また、生産性の観点から、別の問題がありました。さまざまなタイプのレポートを作成できる管理パネルがありました。 しかし同時に、これらのレポートは最適に作成されておらず、しばらくしてから計算に40分かかりました。 たとえば、これらのレポートにはタイプセッターのパフォーマンスの計算が含まれていました。 同時に、これらのレポートは多くの場合、テーブルロックを引き起こしました（これは、スナップショットレベルでのデータベースパフォーマンスの決定の前でした）。 ビジネスロジックによると、これらのレポートは過去1日の情報を示し、営業日の初めに、従業員は管理パネルから生成を開始し、その後、ファイルがネットワークドライブに表示され、全員がそれを監視しました。 同時に、テーブルロックのため、データベースからのすべての更新と削除は定期的に停止されました。

この問題は非常に簡単に解決されました。コンソールユーティリティを作成し、Windowsタスクスケジューラを使用して実行しないように設定しただけで、管理パネルから削除しました。 したがって、ビジネスロジックを保持し（レポートは営業日の開始までに準備ができています）、ロックに関する問題を回避しました。

この問題に関する結論：レポートが生成される頻度と、レポートを準備する時間枠までに分析するのは良いことです。

継承されたプロジェクトで作業中に発生した問題の一部をリストしました。 ソリューションは完璧でしたか？ ほとんどない。

しかし、彼らはプロジェクトを維持し、開発し、それを持続可能にすることを許可し、顧客は私たちと一緒にいました。