首席架構(gòu)師汪洋坐鎮(zhèn)，歡迎大伙提問啊：軟件架構(gòu)連載討論之一：正確認識軟件架構(gòu)

napleon

我的理解就是：所謂架構(gòu)就是將需求拆分為子獨立的子系統(tǒng)，并建立其這些子系統(tǒng)之間的純邏輯系統(tǒng)模型。而通過一些策略和方法，將這些子系統(tǒng)抽象成一些功能模塊，并建立起基于這些功能模塊所提供的接口的調(diào)度關系，就是設計。而將這些模塊接口所要實現(xiàn)的功能用代碼描述出來就是編程實現(xiàn)了。這三者并非有明顯的層次關系，但是初如行者，首先強調(diào)的是高效編寫這些出這類接口實現(xiàn)的技巧。

napleon

而team leader則需要熟悉各種設計模式，能將架構(gòu)模型中的子系統(tǒng)抽象成相互獨立又基于接口松耦合的邏輯模塊的能力。

yanyangtian4502

回復 43# napleon


    架構(gòu)不僅僅只是考慮邏輯的層面，或者說 架構(gòu)不僅僅只是考慮代碼方面的東西，其實更多的時候是綜合的考慮：人，資源，技術(shù)，投資者的利益等

yanyangtian4502

所以一個架構(gòu)做出來之后，我們可以看到的可能就是一些文檔，代碼等，其實這些都只是架構(gòu)的一種反應形式，架構(gòu)！=編寫文檔！

yanyangtian4502

不同的人對架構(gòu)有著不一樣的理解。無論是在建筑行業(yè)、軟件行業(yè)，還是在網(wǎng)絡或書本上，“架構(gòu)”一詞有著各種各樣的解釋。在編程的世界中，很多對架構(gòu)的解釋都是從技術(shù)的層面來定義的，而且在不同的技術(shù)或平臺上面，對架構(gòu)的定義又不太一樣，甚至有些定義和理解失去了其原本的核心意思，這就使得部分架構(gòu)學習者感到迷茫。

如果認為“架構(gòu)”是一個簡單的實體，能夠用一份文檔或一張圖紙來描述，那么你就錯了。確實，架構(gòu)師在為系統(tǒng)創(chuàng)建架構(gòu)時經(jīng)常要做出很多與設計相關的決定，而且會以用文檔的形式記錄下來，但是架構(gòu)和文檔又不是等同的，之所以要以文檔的形式保存，主要是為了便于以后對這些設計決定進行審核和修改，并且將其作為構(gòu)建軟件時的約束和指導。

snow888

所以一個架構(gòu)做出來之后，我們可以看到的可能就是一些文檔，代碼等，其實這些都只是架構(gòu)的一種反應形式，架 ...
yanyangtian4502 發(fā)表于 2011-10-17 14:54

    嚴重同意啊。

架構(gòu)就是對將要實現(xiàn)的系統(tǒng)的抽象話，是將要實現(xiàn)的系統(tǒng)的模型化，這中間即包括物理的，也包括邏輯的，還包括數(shù)據(jù)層的。

俺不同意某些將應用層的組成方式也歸類于架構(gòu)的范疇，俺覺得那應該是系統(tǒng)需求分析的一部分，俺理解的需求分析包括業(yè)務需求方面的分析，也包括為實現(xiàn)業(yè)務需求而對應用的功能模塊的預安排部分。

snow888

暈，又進這帖子了。

AD8018

我的兩個問題，
http://72891.cn/redirec ... 48&pid=21521478
能否就此兩個具體問題解惑一下，謝謝

yanyangtian4502

回復 50# AD8018


    ok，我看看

yanyangtian4502

言歸正傳。
我對系統(tǒng)架構(gòu)上面有兩個疑問，樓主能幫指點一下？

1. 無重構(gòu)沒有好架構(gòu)

   開發(fā)一個項目之前，各方面都想的不錯。
   然而，隨著需求的深入和增加，縫補的東西變多，ctrl-c/ctrl-v的東西變多。
   最后，要么忍受，要么狠心重構(gòu)。
   于是，在我的概念里，就有了這句話 -- 無重構(gòu)沒有好架構(gòu)

   如何做到不重構(gòu)，仍有好架構(gòu)？

回答：在項目開始之前，其實我們對需求和功能不是完全清楚的，這個時候，不會，也不可能將系統(tǒng)架構(gòu)全部做出來。此時只是的設計是最簡單的，采用接口編程的形式，將每個層之間的銜接搞好，便于后續(xù)改動！
改動是在所難免的，很多人認為：架構(gòu)師就是在開始就將整個系統(tǒng)的架構(gòu)全部設計好了，其實這是不對的！架構(gòu)師的在剛剛開始的時候，做出的架構(gòu)也很簡單，目的在于盡可能的是的以后的改動波及到的代碼更少。然后，每次的項目迭代，不斷的將架構(gòu)完善，重構(gòu)也是一個必要的步驟（很不幸的是，在后續(xù)的迭代中，很多公司和人員都不愿意花時間去重構(gòu)了，認為很花時間，并且沒有效果）

2. 多一層架構(gòu)，多一層混亂

   以前迷戀封裝接口之類的東西。其目的，原本是統(tǒng)一和簡化接口，
   最后，還是隨著需求的深入和增加，
   統(tǒng)一和簡化的接口，變成了多增加的接口。

   為什么？其實你沒有簡化接口，原本的接口還在。
   你要強迫別人不用嗎？很難。

回答：設計其實就是追求的簡單，從實際出發(fā)，不做無謂的假設（如果要做假設，那么就要對該項目的領域很清楚）！很多人在設計的時候，為了顯擺自己很�；蛱幱谄渌�的原因，把項目設計的N復雜。

   Win32 API是一層接口，c庫是一層接口，mfc是一層接口。
   哪一層的封裝，都使事情朝著簡單和混沌兩個方向發(fā)展。
   簡單能理解，混沌呢，比如
    CreateThread -> beginthread -> AfxBeginThread
   用的不好會要命。你覺得封裝的結(jié)果，使事情變簡單了，還是變復雜了？

   這是接口設計的例子。反應到設計架構(gòu)上時，俺就如履薄冰，盡量避免無畏的封裝。
   封裝的不好，還不如不封裝。
   最終的結(jié)果，就是你的項目，變成一坨誰都不愿意碰的東西。

   如何避免以上的窘境？

總之：走簡單路線，在開始的時候，設計一個基本的幾層邏輯架構(gòu)就行了，并且每層采用接口實現(xiàn)，后續(xù)項目不斷的迭代，不斷的改進！不要無謂的做很多的假設（不要說：以后可能會這樣等話語）。也不要花盡心思想：這里采用什么模式，那么采用什么原則！等到出現(xiàn)的時候再改！
記�。盒〔襟E，多行動，不斷的改動！沒有萬靈丹！