架構是有關軟體整體結構與元件的抽象描述，用於指導大型軟體系統各個方面的設計。為了對架構有更加深刻的理解和掌握如何進行架構，我閱讀了《架構之美》這本書。這本書是來介紹系統的設計方法的。
首先對架構的基本概念進行了了解。在建築，**，寫作等各種行業都可以看到這個詞的出現.架構是系統設計的一部分，它突出了某些細節，並通過抽象省略掉了另一些細節。軟體系統的架構包括行為上的和結構上的。外部行為描述展示了軟體如何與使用者、其他裝置和外部裝置進行互動，也就是需求。結構描述展示了軟體如何被劃分為多個部分，以及這些部分的關係。
架構是系統設計的一部分，架構設計關注的側重於元件的內部結構。架構的設計受到許多因素的制約，架構是好是壞並沒有統一的標準。這取決於人們對軟體的需求、軟體被構建和執行的環境，以及軟體團隊本身的特點等等因素。評價軟體好壞有很多指標，例如效能、安全、可伸展性等等。一般來說，這些指標是很難全部滿足的，試圖改進其中乙個往往會對其他指標產生負面影響。所以從某種意義上來說，軟體架構是折中的遊戲。對於一組功能需求和品質需求，沒有唯一的正確架構。
好的架構展示了架構完整性，減少複雜性，指導詳細設計和系統驗證。待構建的系統需要具備幾點要求：具備客戶要求的功能；能夠在工期內安全的構造；效能好；可靠；可用；安全；成本適度；符合法規；超越競爭者/前人。因為沒有乙個系統能夠同時滿足所有要求，所以架構是一種折中，挑出最為重要的幾點來實現。
軟體系統就像是一座由建築和後面的路構成的城市，本書使用抽象的例子兩個軟體城市生動的介紹了軟體系統應處於哪種生存模式中。乙個是「混亂的大都市」。並沒有一套健康的架構，通過整個系統的閱讀並不能清楚的各個之間的聯絡。這將帶來一系列的後果。第一：導致這將成為乙個很難讓人理解的系統，這將幾乎不可能修改。新加入專案的成員將不能理解系統。壞的架構設計又繼續會招致更壞的架構。第二：缺乏內聚。每個元件本來應該有乙個良好的角色，但是它們卻包含了一堆雜亂的、不一定相關的功能。這很難弄清楚系統已經實現了哪些具體的功能。第三：**的問題以及**以外的問題。「大都市」的問題隨著時間的推移問題將逐漸變的嚴重不可修復。從這裡清楚的看到缺乏健康的架構的嚴重性。另乙個則是與之相反的「涉及之城」與其最大的差異在於具有健康的架構。
通過這兩者的比較來講，我明白架構在軟體中的重要地位。軟體架構對新產品開發、產品線開發、軟體維護以及軟體公升級都有很重要的作用。是溝通現實世界和計算機世界的一座橋。
閱讀筆記01
許多軟體問題都源於收集 記錄 協商和修改產品需求過程中的方式不當，包括資訊收集方式不正規，沒有明確提出想要的功能，假設是未經過溝通的錯誤假設，需求的定義不夠充分，以及未經仔細考慮進行需求變更等。在軟體開發中遇到的問題時，人們常常輕率地將其忽略。軟體專案中40 60 的缺陷都是由需求分析階段的過失所致...
閱讀筆記01
第一章 01 作為 軟體需求分析教程 的開端,也就是第一章內容為我們介紹了軟體需求分析的一些例項，以及需求的定義。從閱讀的過程中我了解到，任何乙個軟體專案都存在他的需求，與此同時，往往決定專案成功與否的關鍵，也是專案最初階段需求分析的成功與否。在軟體工程中，所有的風險承擔者 stakeholder ...
假期閱讀筆記01
在大三這個寒假我閱讀了 架構之美 這本書，對於架構我之前是有聽說的，但是並沒有很深刻的了解，通過這次對於 架構之美 的閱讀，我了解到架構對架構師，構建者和其他利益相關者有著重要的幫助。乙個合格的系統首先要具備架構的概念，架構是有關軟體整體結構與元件的抽象描述，用於指導大型軟體系統各個方面的設計。當今...