一、什么是架構(gòu)
1. 和架構(gòu)相關(guān)的幾個(gè)問題域
架構(gòu)需要解決的非業(yè)務(wù)問題域包括如下：
A 系統(tǒng)目標(biāo)：系統(tǒng)性能，穩(wěn)定性.
B.項(xiàng)目目標(biāo)：開發(fā)成本，質(zhì)量
C.項(xiàng)目過程：需求的不確定性和開發(fā)過程的團(tuán)隊(duì)協(xié)作性
不同的問題域，解決之道也不相同！而同一問題域的不同層次的要求，解決之道也不盡相同。
2. 什么是架構(gòu)
架構(gòu)到底是啥，愚以為下面的這段英文描述的很清楚。
That's like asking, what is culture? Culture is the way you do things in a group of people. Architecture is the way you do things in a software product. You could argue by analogy, then, that architecture is to a software product as culture is to a team. It is how that team has established and chosen its conventions，
Which leads us inevitably to the question of “goodness”? How do you know if an architecture is good? Consider an architecture that isn't built using a strong domain model, and instead relies heavily on stored procedures. That might be OK, or it might not be OK. You could have decided that part of your architecture is to use a really strong domain model and not use stored procedures, right? So an architecture is some reasonable regularity about the structure of the system, the way the team goes about building its software, and how the software responds and adapts to its own environment. How well the architecture responds and adapts, and how well it goes through that construction process, is a measure of whether that architecture is any good.
The system architecture determines how hard or easy it is to implement a given feature. Good architectures are those in which it is considered easy to create the features desired. In that the way to judge whether an architecture is good is whether the architecture is good for the purposes to which it is applied.
The definition of goodness has to be related to fitness for purpose. Is this glove good? I don't know. What are you doing with the glove? Are you throwing snowballs, cooking barbeques, or playing golf? There's a set of changes that are going to occur to a software system over time. Probably the utilitarian or most useful definition of goodness is the answer to this question: are the changes that will keep this system successful in this domain in this product line relatively easy? If they are, then it's probably a good architecture.
3. 架構(gòu)的背后
為了實(shí)現(xiàn)架構(gòu)的目標(biāo)涉及到以下三個(gè)方面：技術(shù)，組織和過程。這里舉例說明。
1) 技術(shù)對(duì)開發(fā)效率和運(yùn)行性能，以及組織和過程的影響。
案例A．映射的問題。公司產(chǎn)品的一個(gè)重要需求是根據(jù)客戶輸入，映射到PDF文件上。技術(shù)上整體實(shí)現(xiàn)需要四個(gè)步驟：在PDF文件上畫好所有的數(shù)據(jù)域，通過讀入一個(gè)XML映射文件，獲得運(yùn)行數(shù)據(jù)并生成FDF，合并FDF和PDF生成目標(biāo)文件。后兩步工作都由代碼自動(dòng)化了，因而實(shí)現(xiàn)的主要工作在于前兩步。
在第一個(gè)實(shí)現(xiàn)版本里，XML映射文件的DTD太簡(jiǎn)單，致使一個(gè)xml文件至少在4000行左右，同時(shí)xml文件太verbose了。這樣的結(jié)果直接導(dǎo)致運(yùn)行系統(tǒng)在峰值時(shí)，由于XML消耗了大量?jī)?nèi)存，1G的內(nèi)存根本吃不消；同時(shí)對(duì)XML解析執(zhí)行使用了CPU的大量時(shí)間；導(dǎo)致開發(fā)人員需要做大量的工作，開發(fā)效率降低了，通常需要盡一周才能完成一個(gè)xml文件，員工都不愿意做；也導(dǎo)致開發(fā)過程的漫長， 開發(fā)部門對(duì)于BA部門和ST部門的要求反應(yīng)變的緩慢。
在第二個(gè)版本的實(shí)現(xiàn)中，重新實(shí)現(xiàn)了DTD，加入了大量的關(guān)鍵字同時(shí)也消除了verbose，大量的縮小了XML大小，從4000多行減低到900多行。不僅減低了內(nèi)存使用，提高執(zhí)行效率；也提高了開發(fā)效率，基本只要一天就可以完成一個(gè)映射文件。同時(shí)對(duì)BA部門和ST部門的反應(yīng)也快了。
案例B：腳本的問題。產(chǎn)品在web層提供了腳本支持，出于方便開發(fā)的目的。但是沒有對(duì)腳本的環(huán)境限制，腳本可以做系統(tǒng)程序的大部分工作。導(dǎo)致開發(fā)人員偷懶，在web層混入了大量業(yè)務(wù)邏輯代碼。最終造成業(yè)務(wù)邏輯分散而不可控制。
2) 組織結(jié)構(gòu)對(duì)技術(shù)，開發(fā)效率和應(yīng)變能力的影響。
案例A.部門的分工問題。開發(fā)部門根據(jù)不同的職責(zé)，分成A，B和C等數(shù)個(gè)小組。大部分開發(fā)中互不相干。但也有時(shí)候，需要跨組的支持，比如B要實(shí)現(xiàn)某個(gè)需求，需要A在一定條件在記錄一個(gè)或多個(gè)信息。因?yàn)槊總€(gè)開發(fā)人員各自負(fù)責(zé)一部分工作，導(dǎo)致跨組溝通的困難。同時(shí)由于整個(gè)開發(fā)部采取任務(wù)績(jī)效，有時(shí)間壓力，加上只是一個(gè)小的要求。于是在A人員的同意下，B人員直接在A代碼中寫入業(yè)務(wù)邏輯。每次都是這樣的小改動(dòng)，不斷的發(fā)展后，代碼開發(fā)變凌亂。
案例B.開發(fā)的歷史問題，當(dāng)某個(gè)開發(fā)人員寫下的代碼，有是問題的，接手開發(fā)人員由于文檔不全以及沒有測(cè)試用例，不愿意承擔(dān)變化的代價(jià)，選擇小修小補(bǔ)，這個(gè)小修小補(bǔ)有可能和有問題的代碼混雜，導(dǎo)致更大的代碼。
3) 過程對(duì)開發(fā)效率和應(yīng)變能力，以及組織的影響
案例A.過程的問題。開發(fā)部門的上下游部門BA部門和ST部門的合作關(guān)系。ST部門的績(jī)效考核,考核基于發(fā)現(xiàn)錯(cuò)誤的數(shù)量，導(dǎo)致ST為了完成任務(wù)，提出一些非正常性要求。PM部門出于部門的方便通常提出一些實(shí)現(xiàn)難度比較大要求。開發(fā)部門本身又存在時(shí)間壓力，導(dǎo)致一些需求的實(shí)現(xiàn)本應(yīng)在低一層的代碼中實(shí)現(xiàn)的，卻在高層用蹩足的方式實(shí)現(xiàn)。
案例B.幫助系統(tǒng)的問題。幫助系統(tǒng)一開始采用一個(gè)個(gè)單獨(dú)分散的靜態(tài)頁面。出于性能的考慮和部門負(fù)責(zé)考慮。幫助系統(tǒng)不斷改進(jìn)中，過程缺乏組織性，文件的命名規(guī)則隨意，存儲(chǔ)位置隨意，造成了管理的混亂。直接的后果是頁面的入口混亂和各自引用關(guān)系混亂。
在幫助系統(tǒng)的第二版，從靜態(tài)頁面轉(zhuǎn)成動(dòng)態(tài)頁面。采取統(tǒng)一分類和命名規(guī)則，并統(tǒng)一了入口。同時(shí)采取分級(jí)管理引用關(guān)系，適度冗余。雖然減低了運(yùn)行性能。但提高了開發(fā)效率和可維護(hù)性。
1. 和架構(gòu)相關(guān)的幾個(gè)問題域
架構(gòu)需要解決的非業(yè)務(wù)問題域包括如下：
A 系統(tǒng)目標(biāo)：系統(tǒng)性能，穩(wěn)定性.
B.項(xiàng)目目標(biāo)：開發(fā)成本，質(zhì)量
C.項(xiàng)目過程：需求的不確定性和開發(fā)過程的團(tuán)隊(duì)協(xié)作性
不同的問題域，解決之道也不相同！而同一問題域的不同層次的要求，解決之道也不盡相同。
2. 什么是架構(gòu)
架構(gòu)到底是啥，愚以為下面的這段英文描述的很清楚。
That's like asking, what is culture? Culture is the way you do things in a group of people. Architecture is the way you do things in a software product. You could argue by analogy, then, that architecture is to a software product as culture is to a team. It is how that team has established and chosen its conventions，
Which leads us inevitably to the question of “goodness”? How do you know if an architecture is good? Consider an architecture that isn't built using a strong domain model, and instead relies heavily on stored procedures. That might be OK, or it might not be OK. You could have decided that part of your architecture is to use a really strong domain model and not use stored procedures, right? So an architecture is some reasonable regularity about the structure of the system, the way the team goes about building its software, and how the software responds and adapts to its own environment. How well the architecture responds and adapts, and how well it goes through that construction process, is a measure of whether that architecture is any good.
The system architecture determines how hard or easy it is to implement a given feature. Good architectures are those in which it is considered easy to create the features desired. In that the way to judge whether an architecture is good is whether the architecture is good for the purposes to which it is applied.
The definition of goodness has to be related to fitness for purpose. Is this glove good? I don't know. What are you doing with the glove? Are you throwing snowballs, cooking barbeques, or playing golf? There's a set of changes that are going to occur to a software system over time. Probably the utilitarian or most useful definition of goodness is the answer to this question: are the changes that will keep this system successful in this domain in this product line relatively easy? If they are, then it's probably a good architecture.
3. 架構(gòu)的背后
為了實(shí)現(xiàn)架構(gòu)的目標(biāo)涉及到以下三個(gè)方面：技術(shù)，組織和過程。這里舉例說明。
1) 技術(shù)對(duì)開發(fā)效率和運(yùn)行性能，以及組織和過程的影響。
案例A．映射的問題。公司產(chǎn)品的一個(gè)重要需求是根據(jù)客戶輸入，映射到PDF文件上。技術(shù)上整體實(shí)現(xiàn)需要四個(gè)步驟：在PDF文件上畫好所有的數(shù)據(jù)域，通過讀入一個(gè)XML映射文件，獲得運(yùn)行數(shù)據(jù)并生成FDF，合并FDF和PDF生成目標(biāo)文件。后兩步工作都由代碼自動(dòng)化了，因而實(shí)現(xiàn)的主要工作在于前兩步。
在第一個(gè)實(shí)現(xiàn)版本里，XML映射文件的DTD太簡(jiǎn)單，致使一個(gè)xml文件至少在4000行左右，同時(shí)xml文件太verbose了。這樣的結(jié)果直接導(dǎo)致運(yùn)行系統(tǒng)在峰值時(shí)，由于XML消耗了大量?jī)?nèi)存，1G的內(nèi)存根本吃不消；同時(shí)對(duì)XML解析執(zhí)行使用了CPU的大量時(shí)間；導(dǎo)致開發(fā)人員需要做大量的工作，開發(fā)效率降低了，通常需要盡一周才能完成一個(gè)xml文件，員工都不愿意做；也導(dǎo)致開發(fā)過程的漫長， 開發(fā)部門對(duì)于BA部門和ST部門的要求反應(yīng)變的緩慢。
在第二個(gè)版本的實(shí)現(xiàn)中，重新實(shí)現(xiàn)了DTD，加入了大量的關(guān)鍵字同時(shí)也消除了verbose，大量的縮小了XML大小，從4000多行減低到900多行。不僅減低了內(nèi)存使用，提高執(zhí)行效率；也提高了開發(fā)效率，基本只要一天就可以完成一個(gè)映射文件。同時(shí)對(duì)BA部門和ST部門的反應(yīng)也快了。
案例B：腳本的問題。產(chǎn)品在web層提供了腳本支持，出于方便開發(fā)的目的。但是沒有對(duì)腳本的環(huán)境限制，腳本可以做系統(tǒng)程序的大部分工作。導(dǎo)致開發(fā)人員偷懶，在web層混入了大量業(yè)務(wù)邏輯代碼。最終造成業(yè)務(wù)邏輯分散而不可控制。
2) 組織結(jié)構(gòu)對(duì)技術(shù)，開發(fā)效率和應(yīng)變能力的影響。
案例A.部門的分工問題。開發(fā)部門根據(jù)不同的職責(zé)，分成A，B和C等數(shù)個(gè)小組。大部分開發(fā)中互不相干。但也有時(shí)候，需要跨組的支持，比如B要實(shí)現(xiàn)某個(gè)需求，需要A在一定條件在記錄一個(gè)或多個(gè)信息。因?yàn)槊總€(gè)開發(fā)人員各自負(fù)責(zé)一部分工作，導(dǎo)致跨組溝通的困難。同時(shí)由于整個(gè)開發(fā)部采取任務(wù)績(jī)效，有時(shí)間壓力，加上只是一個(gè)小的要求。于是在A人員的同意下，B人員直接在A代碼中寫入業(yè)務(wù)邏輯。每次都是這樣的小改動(dòng)，不斷的發(fā)展后，代碼開發(fā)變凌亂。
案例B.開發(fā)的歷史問題，當(dāng)某個(gè)開發(fā)人員寫下的代碼，有是問題的，接手開發(fā)人員由于文檔不全以及沒有測(cè)試用例，不愿意承擔(dān)變化的代價(jià)，選擇小修小補(bǔ)，這個(gè)小修小補(bǔ)有可能和有問題的代碼混雜，導(dǎo)致更大的代碼。
3) 過程對(duì)開發(fā)效率和應(yīng)變能力，以及組織的影響
案例A.過程的問題。開發(fā)部門的上下游部門BA部門和ST部門的合作關(guān)系。ST部門的績(jī)效考核,考核基于發(fā)現(xiàn)錯(cuò)誤的數(shù)量，導(dǎo)致ST為了完成任務(wù)，提出一些非正常性要求。PM部門出于部門的方便通常提出一些實(shí)現(xiàn)難度比較大要求。開發(fā)部門本身又存在時(shí)間壓力，導(dǎo)致一些需求的實(shí)現(xiàn)本應(yīng)在低一層的代碼中實(shí)現(xiàn)的，卻在高層用蹩足的方式實(shí)現(xiàn)。
案例B.幫助系統(tǒng)的問題。幫助系統(tǒng)一開始采用一個(gè)個(gè)單獨(dú)分散的靜態(tài)頁面。出于性能的考慮和部門負(fù)責(zé)考慮。幫助系統(tǒng)不斷改進(jìn)中，過程缺乏組織性，文件的命名規(guī)則隨意，存儲(chǔ)位置隨意，造成了管理的混亂。直接的后果是頁面的入口混亂和各自引用關(guān)系混亂。
在幫助系統(tǒng)的第二版，從靜態(tài)頁面轉(zhuǎn)成動(dòng)態(tài)頁面。采取統(tǒng)一分類和命名規(guī)則，并統(tǒng)一了入口。同時(shí)采取分級(jí)管理引用關(guān)系，適度冗余。雖然減低了運(yùn)行性能。但提高了開發(fā)效率和可維護(hù)性。