100,000週間でXNUMX万行のコードを読んで修正する方法

大規模で古いプロジェクトを理解するのは、最初はいつも困難です。 建築は建築家評価の活動の XNUMX つです。 通常、大規模で古いプロジェクトに取り組む必要があり、結果は XNUMX 週間以内に提出されなければなりません。

100 万行以上のコードからなるプロジェクトを XNUMX 週間で評価しながら、クライアントにとって本当に役立つ結果を提供する方法。

ほとんどのアーキテクトや技術リーダーは、同様のプロジェクト評価に遭遇したことがあります。 これは、半正式なプロセスのように見えるかもしれませんし、当社で行われているように別のサービスとして見えるかもしれませんが、ほとんどの方が何らかの方法でこれに対処したことがあります。

ロシア語を話さない友人向けの英語の原文はこちらです。 XNUMX 週間でのアーキテクチャ評価.

当社の取り組み

私たちの会社でそれがどのように機能するか、そして同様の状況で私がどのように行動するかを説明しますが、このアプローチはプロジェクトや会社のニーズに応じて簡単に変更できます。

アーキテクチャ評価には XNUMX 種類あります。

内部 – 私たちは通常、社内のプロジェクトのためにそれを行います。 どのプロジェクトでも、次のような理由でアーキテクチャ評価を要求することがあります。

1. チームは自分たちのプロジェクトは完璧だと考えていますが、これには疑問があります。 私たちにもそのようなケースがありましたが、そのようなプロジェクトではすべてが理想から程遠いことがよくあります。
2. チームはプロジェクトとソリューションをテストしたいと考えています。
3. チームは事態が悪いことを知っている。 主な問題と原因を列挙することもありますが、問題の完全なリストとプロジェクトを改善するための推奨事項が必要です。

外部の 内部評価よりも正式なプロセスです。 クライアントは常に、すべてが悪い場合、つまり非常に悪い場合にのみ来ます。 通常、クライアントは全体的な問題があることは理解していますが、原因を正しく特定してコンポーネントに分解することはできません。

外部クライアントのアーキテクチャを評価する場合は、より複雑になります。 このプロセスはより正式なものであるべきです。 プロジェクトは常に大きくて古いものです。 彼らにはたくさんの問題、バグ、そして曲がったコードがあります。 完了した作業に関するレポートは最大で数週間以内に作成され、主な問題点と改善のための推奨事項が含まれます。 したがって、プロジェクトの外部評価に対処すれば、内部評価は朝飯前になります。 最も困難なケースを考えてみましょう。

エンタープライズ プロジェクト アーキテクチャの評価

評価すべき一般的なプロジェクトは、多くの問題を抱えた大規模で古いエンタープライズ プロジェクトです。 クライアントが私たちのところに来て、自分のプロジェクトを修正してほしいと頼んできました。 これは氷山のようなもので、クライアントは問題のほんの一部しか見えておらず、水の下 (コードの深さ) に何があるのか​​わかりません。

顧客が苦情を申し立て、認識している可能性がある問題:

• パフォーマンスの問題
• ユーザビリティの問題
• 長期的な展開
• 単体テストやその他のテストの欠如

クライアントが気づいていない可能性が高い問題ですが、プロジェクト内に存在する可能性があります。

• 安全上の問題
• 設計上の問題
• 間違ったアーキテクチャ
• アルゴリズムエラー
• 不適切な技術
• 技術的負債
• 間違った開発プロセス

正式なアーキテクチャレビュープロセス

これは会社として従う正式なプロセスですが、会社やプロジェクトに応じてカスタマイズできます。

クライアントからのリクエスト

クライアントは、現在のプロジェクトのアーキテクチャを評価するように求めています。 弊社側の責任者は、プロジェクトに関する基本情報を収集し、必要な専門家を選定します。 プロジェクトによっては、これらの専門家が異なる場合があります。

ソリューションアーキテクト – 評価と調整の主な責任者 (多くの場合、唯一の責任者)。
特定の専門家をスタックする – プロジェクトとテクノロジーに応じて、.Net、Java、Python、およびその他の技術スペシャリスト
クラウドの専門家 – これらは、Azure、GCP、または AWS クラウド アーキテクトです。
インフラ – DevOps、システム管理者など
他の専門家 – ビッグデータ、機械学習、パフォーマンス エンジニア、セキュリティ専門家、QA リーダーなど。

プロジェクトに関する情報を収集する

プロジェクトについてできるだけ多くの情報を収集する必要があります。 状況に応じてさまざまなテクニックを使用できます。

• メールによるアンケートその他の連絡方法。 最も効果のない方法。
• オンライン会議。
• Google ドキュメント、Confluence、リポジトリなどの情報交換用の特別なツール。
• 現場での「ライブ」ミーティング。 最も効果的で最も高価な方法です。

クライアントから何を得る必要がありますか？

基本情報。 プロジェクトとは何ですか? その目的と価値。 主な目標と将来の計画。 ビジネスの目標と戦略。 主な問題点と望ましい結果。

プロジェクト情報。 テクノロジースタック、フレームワーク、プログラミング言語。 オンプレミスまたはクラウドの展開。 プロジェクトがクラウド上にある場合、使用されるサービス。 どのようなアーキテクチャパターンとデザインパターンが使用されたか。

非機能要件。 システムのパフォーマンス、可用性、使いやすさに関するすべての要件。 安全要件など

基本的な使用例とデータ フロー。

ソースコードへのアクセス。 最も重要な部分です！ プロジェクトの構築方法に関するリポジトリとドキュメントに確実にアクセスできるようにする必要があります。

インフラへのアクセス。 ライブ システムを操作するためにステージまたはプロダクション インフラストラクチャにアクセスできれば便利です。 クライアントがインフラストラクチャとパフォーマンスを監視するツールを備えていれば、これは大成功です。 これらのツールについては次のセクションで説明します。

Документация。 クライアントがドキュメントを持っている場合は、これが良いスタートとなります。 時代遅れかもしれませんが、それでも良いスタートです。 ドキュメントを決して信頼しないでください。クライアントを使用して、実際のインフラストラクチャおよびソース コードでテストしてください。

アーキテクチャの評価プロセス

どうすればこれほど大量の情報を短時間で処理できるのでしょうか? まず、作業を並列化します。

DevOps はインフラストラクチャに注目する必要があります。 コードへの技術的なリード。 パフォーマンス エンジニアはパフォーマンス メトリックを表示します。 データベースの専門家は、データ構造をさらに深く掘り下げる必要があります。

ただし、これはリソースが豊富にある場合の理想的なケースです。 通常、XNUMX 人から XNUMX 人がプロジェクトを評価します。 プロジェクトのすべての分野で適切な知識と経験がある場合は、見積もりを自分で行うこともできます。 この場合、すべてのプロセスを可能な限り自動化する必要があります。

残念ながら、マニュアルを手動で読む必要があります。 適切な経験があれば、ドキュメントの品質をすぐに理解できます。 何が真実で、何が明らかに現実と一致しないのか。 場合によっては、実際には動作しないアーキテクチャがドキュメントに含まれることがあります。 実際にプロジェクトでどのように行われたのかを考えるきっかけになります。

プロジェクト評価を自動化する便利なツール

コードの評価は簡単な作業です。 静的コード アナライザーを使用すると、設計、パフォーマンス、セキュリティの問題を確認できます。 そのうちのいくつかを次に示します。

構造101 建築家にとって素晴らしいツールです。 全体像、モジュール間の依存関係、リファクタリングの可能性のある領域が表示されます。 すべての優れたツールと同様に、かなりの費用がかかりますが、30 日間の試用版を利用できます。

ソナーキューブ - 古き良きツール。 静的コード分析のためのツール。 20 を超えるプログラミング言語の不正なコード、バグ、セキュリティ上の問題を特定できます。

すべてのクラウド プロバイダーはインフラストラクチャ監視ツールを備えています。 これにより、コストとパフォーマンスの観点からインフラストラクチャの有効性を適切に評価できるようになります。 AWSの場合はこれです 信頼できるアドバイザー。 アズールなら簡単だよ Azureアドバイザー.

追加のパフォーマンス監視とログ記録は、あらゆるレベルでのパフォーマンスの問題の発見に役立ちます。 非効率なクエリを含むデータベースから始まり、バックエンド、そしてフロントエンドで終わります。 クライアントがこれらのツールを以前にインストールしていない場合でも、これらのツールを既存のシステムにすぐに統合して、パフォーマンスの問題を特定できます。

いつものように、優れたツールにはそれだけの価値があります。 有料ツールをいくつかお勧めします。 もちろんオープンソースを使用することもできますが、より時間がかかります。 そして、これはアーキテクチャの評価プロセス中ではなく、事前に行う必要があります。

新しいレリック – アプリケーションのパフォーマンスを評価するツール
データドッグ – クラウドシステム監視サービス

セキュリティテストに利用できるツールは数多くあります。 今回は無料のシステムスキャンツールをお勧めします。

OWASP ザップ – Web アプリケーションをスキャンしてセキュリティ標準に準拠するためのツール。

すべてを一つの全体にまとめましょう。

レポートの準備

クライアントから収集したデータからレポートを開始します。 プロジェクトの目標、制約、非機能要件を説明します。 この後、ソース コード、ドキュメント、インフラストラクチャなど、すべての入力データについて言及する必要があります。

次のステップ。 手動または自動ツールを使用して見つけた問題をリストします。 大きな自動生成レポートはアプリケーション セクションの最後に配置します。 見つかった問題の短くて簡潔な証拠が必要です。
エラー、警告、情報のスケールで見つかった問題に優先順位を付けます。 独自のスケールを選択することもできますが、これが一般的に受け入れられているスケールです。

真のアーキテクトとして、見つかった問題を修正するための推奨事項を提供するのはあなたの責任です。 顧客が得られる改善点とビジネス価値について説明します。 ビジネス価値をどのように示すか アーキテクチャのリファクタリング 先ほど議論しました。

小さな反復を伴うロードマップを準備します。 各反復には、完了までの時間、説明、改善に必要なリソースの量、技術的価値、ビジネス価値が含まれている必要があります。

アーキテクチャ評価を完了し、クライアントにレポートを提供します

決してレポートを郵送するだけではありません。 まったく読まれないかもしれないし、適切な説明がなければ読んで理解できないかもしれない。 つまり、ライブコミュニケーションは人々の間の誤解を取り除くのに役立ちます。 クライアントとのミーティングをスケジュールし、最も重要な問題に焦点を当てて、見つかった問題について話し合う必要があります。 クライアントが気づいていないかもしれない問題にクライアントの注意を引くことは価値があります。 セキュリティ問題などを取り上げ、それがビジネスにどのような影響を与える可能性があるかを説明します。 改善を含むロードマップを示し、クライアントにより適したさまざまなオプションについて話し合います。 これは、時間、リソース、作業量などです。

ミーティングの概要として、レポートをクライアントに送信します。

結論

アーキテクチャの評価は複雑なプロセスです。 適切に評価を行うには、十分な経験と知識が必要です。

わずか XNUMX 週間でクライアントとそのビジネスに役立つ結果を提供することが可能です。 たとえ一人でやっても。

私の経験によると、多くの改良点は途中でダウンロードされ、開始されない場合もありました。 自分自身で黄金の中庸を選択し、最小限の人件費でビジネスに最も役立つ改善の一部のみを行った企業は、製品の品質を大幅に向上させました。 何もしなかった人は、数年後にプロジェクトを完全に終了する可能性があります。

あなたの目標は、クライアントに最小限の価格で最大限の改善を示すことです。

このセクションの他の記事 建築 自由に読むことができます。

クリーンなコードと適切なアーキテクチャ上の決定をお祈りします。

私たちのフェイスブックグループ - ソフトウェアのアーキテクチャと開発.

出所： habr.com