在這次開發中吸取到的最重要的經驗就是 關於軟體架構的設計，及面向物件的思想。

在最開始的設計中，我將資料中心的儲存，CPU，記憶體的使用率當作物件去設計，而沒有考慮到他們本身是資料中心的屬性，而我最終要彙總分析的是各個資料中心的所有屬性，而不是將每一個屬性進行單獨的計算。所以在程式碼進行到一半時，就是開始變得龐雜並且缺乏條理性和邏輯性，感謝我的同事提醒了我，否則程式碼很快將會徹底崩壞，繼續開發和維護的可能性極低。

在同事的幫助下，重新進行梳理，我最終需要寫入到表中的內容是資料中心的各種指標的平均及總量，而這些指標應該是做為資料中心的屬性存在的，所以最頂級的物件應該是資料中心，而資料中心並不直接管理儲存，與資料中心想關聯的是資料中心底下各個資源池，而在資源池就可以管理儲存，CPU，記憶體效能資源。所以以儲存為例，儲存效能的採集應該分為三層結構：

資料中心 - 資源池 - 儲存

儲存層將各個儲存的具體指標資料匯聚到資源池中，而資源池層將各種池中的資料彙總返回給相應的資料中心，在資料中心層，匯聚出各個資料中心的具體指標，將結果放入資料中心物件的List中返回。這樣的分層結構簡潔清晰，後期進行時，日，周，月的資料彙總和CPU，記憶體的指標開發都是簡單可靠。

那麼，我的設計失敗在什麼地方。

首先，我在設計之初，並沒有考慮到向資料中心進行彙總的需求，我一開始以為只是拼接出查詢SQL和寫入SQL，然後JDBC執行就可以了。這應該說是軟體工程方面的經驗和見識太過淺薄。

其次，單純地考慮這個以儲存為物件的設計，在這個物件中，我定義好了利用率屬性，也就是說，最後寫入到資料庫中的是儲存物件的屬性，那麼，又如何保證寫入的是相應資料中心的儲存呢，如何在儲存物件中新增資料中心屬性，那也就是將資料中心-資源池-儲存是三層對映關係改為了資料中心-儲存的簡單對映關係，這樣的設計，程式碼難度和可靠性都不盡如人意。我真的懷疑，靠我那樣寫法，我可能連一個需求都無法開發完成。

總結，從本次開發任務中學到的經驗：

第一，在進行面向物件的軟體設計時，首先應該思考這次開發需要實現的功能有哪些，為了實現這些功能應當怎樣去設計所需要的物件(我認為這是最重要也是最難的一點，雖然表面是隻是一個積累和思考的過程，但是要隨時保持一個大局觀)。洞悉所有需要用到的物件和屬性，並理清他們之間的關係，每一個物件應該有什麼樣的屬性，而每一個物件又實現了怎樣的功能，最後，這些物件如何有機地結合起來完成所要的需求。這需要不斷地練習，思考，進步。

第二，是關於資料庫設計的。在本次需求中，有很重要的一點就是匯聚的時間控制，當所採集指標的時間跨度拉長到周和月時，如何保證每個屬性的每個指標在相應的跨度中只存在一條記錄。這個如果單純用程式碼實現，會很複雜，而負責資料庫的同事用一張time_map表解決了這個問題。每個跨度在該表中有唯一id，根據當前時間查詢該id，然後去記錄儲存表中的aggregation_time欄位尋找該id，有則更新，無則插入。這樣一個精巧的資料庫設計解決了很多程式碼上的問題，這實在讓我喜歡，並且意識到，在軟體領域，我的路還有很長，相應的，我能看到的風景同樣很多很美。