一開始理解一個大而老的專案總是很困難。 建築是建築師評估的活動之一。 通常，您必須處理大型、舊的項目，並且必須在一周內交付結果。
如何在一周內評估包含 100 萬行或更多程式碼的項目，同時仍提供對客戶真正有用的結果。
大多數架構師和技術主管都曾經遇到類似的專案評估。 這可能看起來像一個半正式的流程，或者像我們公司那樣作為一項單獨的服務，大多數人都以某種方式處理過這個問題。
為您的非俄語朋友提供的英文原件在這裡： .
我們公司的做法
我將告訴您它在我們公司的運作方式以及我在類似情況下的行為方式，但您可以根據您的專案和公司的需求輕鬆更改此方法。
架構評估有兩種類型。
內部的 – 我們通常為公司內部的專案這樣做。 任何專案都可能出於以下幾個原因要求進行架構評估：
- 團隊認為他們的專案是完美的，這是可疑的。 我們曾經遇過這樣的案例，而且往往在這樣的專案中一切都遠非理想。
- 團隊想要測試他們的專案和解決方案。
- 團隊知道情況很糟。 他們甚至可能列出主要問題和原因，但想要一份完整的問題清單和改進項目的建議。
外部的 是一個比內部評估更正式的過程。 客戶總是只在一種情況下出現，即一切都很糟糕——非常糟糕。 通常，客戶知道存在全局問題，但無法正確識別原因並將其分解為多個組件。
評估外部客戶端的架構是一個更複雜的情況。 這個過程應該要更加正式。 這些項目總是又大又舊。 他們有很多問題、錯誤和錯誤的程式碼。 已完成工作的報告應最多在幾週內準備好，其中應包括主要問題和改進建議。 因此，如果我們處理專案的外部評估，那麼內部評估就小菜一碟了。 讓我們考慮最困難的情況。
企業專案架構評估
要評估的典型專案是一個存在許多問題的大型、舊的企業專案。 一位客戶找到我們並要求我們修復他的專案。 就像一座冰山一樣，客戶只看到問題的一角，不知道水下（程式碼深處）有什麼。
客戶可能抱怨和可能意識到的問題：
- 性能問題
- 可用性問題
- 長期部署
- 缺乏單元和其他測試
客戶很可能沒有意識到但專案中可能存在的問題：
- 安全問題
- 設計問題
- 錯誤的架構
- 演算法錯誤
- 不適當的技術
- 技術債
- 錯誤的開發流程
正式的架構審查流程
這是我們作為公司遵循的正式流程，但您可以根據您的公司和專案進行自訂。
來自客戶的請求
客戶要求評估目前專案的架構。 我方負責人收集專案基本資訊並選擇必要的專家。 根據專案的不同，這些專家可能是不同的。
解決方案架構師 – 負責評估和協調的主要人員（通常是唯一的人員）。
堆疊特定專家 – .Net、Java、Python 和其他技術專家（取決於專案和技術）
雲端專家 – 這些可以是 Azure、GCP 或 AWS 雲端架構師。
基礎設施 – DevOps、系統管理員等
其他專家 – 例如大數據、機器學習、效能工程師、安全專家、QA 主管。
收集有關項目的信息
您應該收集盡可能多的有關該項目的資訊。 您可以根據情況使用不同的技術：
- 問卷調查和其他透過郵件溝通的方法。 最無效的方法。
- 線上會議。
- 資訊交換的專用工具如：Google doc、Confluence、儲存庫等。
- 現場“即時”會議。 最有效也是最昂貴的方法。
你該從客戶身上得到什麼？
基本資訊。 該專案是關於什麼的？ 它的目的和價值。 未來的主要目標和計劃。 業務目標和策略。 主要問題和期望的結果。
專案資訊。 技術堆疊、框架、程式語言。 本地或雲端部署。 如果項目在雲端，使用什麼服務。 使用了哪些架構和設計模式。
非功能性需求。 所有要求都與系統的性能、可用性和易用性相關。 安全要求等
基本用例和資料流。
存取原始碼。 最重要的部分！ 您絕對應該存取有關如何建立專案的儲存庫和文件。
使用基礎設施。 如果能夠訪問舞台或製作基礎設施來使用現場系統，那就太好了。 如果客戶擁有用於監控基礎設施和效能的工具，那就是巨大的成功。 我們將在下一節中討論這些工具。
Документация。 如果客戶有文檔，這是一個好的開始。 它可能已經過時了，但仍然是一個好的開始。 永遠不要相信文件 - 與客戶端一起在真實的基礎設施和原始程式碼中進行測試。
架構評估流程
一個人如何在如此短的時間內處理如此大量的資訊？ 首先，並行化工作。
DevOps 應該專注於基礎架構。 技術引入代碼。 性能工程師查看性能指標。 資料庫專家應該更深入地研究資料結構。
但這是當您擁有大量資源時的理想情況。 通常，一到三個人評估一個項目。 您甚至可以自己進行估算，如果您在專案的所有領域都擁有適當的知識和經驗，通常會發生這種情況。 在這種情況下，您需要盡可能自動化所有流程。
不幸的是，您必須手動閱讀文件。 憑藉適當的經驗，您可以快速了解文件的品質。 什麼是真實的，什麼顯然與現實不符。 有時您可能會在文件中看到在現實生活中永遠無法工作的架構。 這會觸發你思考專案中的實際情況是如何完成的。
自動化專案評估的有用工具
程式碼評估是一個簡單的練習。 您可以使用靜態程式碼分析器來顯示設計、效能和安全性問題。 這裡有幾個：
對建築師來說是一個很棒的工具。 它將向您展示全局、模組之間的依賴關係以及潛在的重構領域。 就像所有好的工具一樣，它需要花費很多錢，但您可以利用 30 天的試用版。
- 一個很好的舊工具。 靜態程式碼分析工具。 讓您識別 20 多種程式語言的不良程式碼、錯誤和安全性問題。
所有雲端供應商都有基礎設施監控工具。 這將使您能夠在成本和性能方面正確評估基礎設施的有效性。 對AWS來說這是 。 Azure 很容易 .
額外的效能監控和日誌記錄將有助於發現各個層級的效能問題。 從查詢無效的資料庫開始，到後端，到前端結束。 即使客戶之前沒有安裝這些工具，您也可以相當快速地將它們整合到現有系統中以識別效能問題。
一如既往，好的工具是值得的。 我可以推薦一些付費工具。 當然你可以使用開源，但它會花費你更多的時間。 這應該預先完成，而不是在架構評估過程中完成。
– 評估應用程式效能的工具
– 雲端系統監控服務
有許多工具可用於安全測試。 這次我推薦給大家免費的系統掃描工具。
– 掃描 Web 應用程式是否符合安全標準的工具。
讓我們將所有內容整合為一個整體。
準備報告
從您從客戶收集的數據開始您的報告。 描述專案目標、限制、非功能需求。 此後，應提及所有輸入資料：原始碼、文件、基礎設施。
下一步。 列出您手動或使用自動化工具發現的所有問題。 將大型自動產生的報告放在應用程式部分的末尾。 所發現的問題應該有簡短明了的證據。
優先考慮在錯誤、警告、資訊範圍內發現的問題。 您可以選擇自己的比例，但這是普遍接受的比例。
作為一名真正的架構師，您有責任提供建議來糾正所發現的問題。 描述客戶將獲得的改進和商業價值。 如何展現商業價值 我們之前討論過。
準備一個小迭代的路線圖。 每次迭代應包含完成時間、描述、改善所需的資源量、技術價值和業務價值。
我們完成架構評估並向客戶提供報告
切勿僅郵寄報告。 它可能根本不被閱讀，或者在沒有適當解釋的情況下可能無法閱讀和理解。 簡而言之，即時溝通有助於消除人與人之間的誤解。 您應該安排與客戶的會議並討論發現的問題，重點關注最重要的問題。 值得讓客戶注意他可能沒有意識到的問題。 例如安全問題並解釋它們如何影響業務。 展示您的改進路線圖，並討論更適合客戶的不同選項。 這可能是時間、資源、工作量。
作為會議摘要，將報告發送給客戶。
總之
架構評估是一個複雜的過程。 為了正確地進行評估，您需要有足夠的經驗和知識。
可以在短短一周內為客戶提供對他和他的業務有用的結果。 即使你一個人做。
根據我的經驗，很多改進都是中途下載的，有時根本沒有開始。 那些為自己選擇中庸之道並僅以最低的勞動力成本進行對企業最有用的部分改進的人顯著提高了產品品質。 那些不採取任何行動的人可能會在幾年後完全關閉該項目。
您的目標是以最低的價格向客戶展示最大的改進。
該部分的其他文章 您可以在閒暇時閱讀。
我希望你有乾淨的程式碼和良好的架構決策。
我們的臉書群組 - .
來源： www.habr.com