作者 郭曉剛 發布于 2007年12月29日 上午10時13分

社區

Architecture

主題

InfoQ聲明

架構社區是年輕的InfoQ里面最年輕的一個社區，誕生只有半年時間。在“架構”這個意思不是很明確的大詞背后，我們倒是做了不少實實在在的討論。

其實在這個社區里沒有什么“新聞”，這么說的原因是，一方面報道的內容多半不是新聞事件，而是言論交鋒；另一方面討論的內容也常常是把我們習以為常的舊東西再拿出來重新剖析。而且討論的問題也不見得會有一定的答案，不過我們的目的也不是尋找公式化的回答，我們要的是想清楚每個選擇的利弊和權衡。

要是能讓開發者反思，再反思，這個社區的目的也就達到了吧。

1.DSL：單一語言開發的終結者？
許多年以來，對于軟件項目，企業軟件開發的主流實踐一直都傾向于在單一的通用編程語言上進行標準化，從而使得Java和C#成為今天編程語言的主流選擇。隨著越來越多的目光開始投向DSL，也許我們的前腳已經踏在了一道新的門檻之上，向前望去，我們會發現在軟件項目中采用多種語言已經成為一個標準，但80年代和90年代初出現的問題不會重現。

點評：DSL離“領域專家說的語言”還很遠，“讓領域專家去編程”已經基本被MDA、BPM的實踐所否定。不過，我們已經從為工作選擇合適的工具、框架，進步到了為工作選擇合適的語言，不管OOP、AOP、FP……通通為我所用。再說，XML配置、連貫接口這些不是很像語言的DSL，我們已經用很久了吧。

2.真正的線性可伸縮性需要新的模式和中間件架構嗎？
Nati Shalom聲稱已有基于分層的中間件不能用于真正的線性可伸縮性。他提出了新的基于自給自足處理單元的中間件棧（middleware stack）作為替代，它支持分區/向外擴展（scale-out）模型。幾年前，微軟的Pat Helland就提出了某種事務性模式及形式描述，它們可被用在被他稱為準無限可伸縮的系統中。

點評：Web 2.0一流行，可伸縮性就很敏感了。數據分區、緩存共享、讀寫分離……一直到極端的完全無狀態模型，那么多努力的成果讓投入/產出的曲線多少變直了一些。棘手的事務問題這此也給出了不錯的解決方案。不過，成天可伸縮性掛在嘴邊的人，還是要先問一下自己，到底什么是可伸縮性。

3.API設計的“不可承受之輕”
API的設計影響著所有的開發者。有些API用起來很舒服，而有些則用起來讓人焦頭爛額，更有甚者，讓人完全喪失了繼續用這套API來做開發的勇氣。但它們的區別在哪里呢？是哪種品質會讓一套API易用而另一套復雜難解？ACM Queue最近剛發布了Michi Henning的一篇有關API設計的文章，在文中作者對這些方面進行了分析。

點評：API設計是一件基本但重要的事情，但好像我們都沒有這方面的系統教育。

4.軟件架構的十大錯誤
IASA成員Eoin Woods發表了一篇文章講述他所認為的十大軟件架構錯誤——常常要碰得頭破血流才會得到的一些教訓。

點評：每個人都犯過的錯誤，也還要再犯的錯誤。希望下次再犯的時候，知道自己錯在哪里就好了。這樣想太悲觀了嗎？

5.一圖勝千言?
一圖總是勝過千言？Dean Wampler在新文章《為什么我們要寫代碼而不只是畫圖就好》中主張，在軟件行業里，前面那句話通常要反過來說才對。

點評：不管圖形還是文字，說到底還是要看它的抽象程度適合不適合要表達的內容。

6.為靈活性和健壯性而設計：異步消息模型、OOP和函數式編程
按照Pragmatic Programmers的說法在OOP中最好避免圍繞返回值來設計。Michael Feathers認為最好同時也使用異步消息模型，這樣有助于提高適應性和健壯性。這樣的做法與Erlang的模型相吻合，雖然違背了一些純函數式編程的原則。

點評：異步、無狀態模型的優點很多人都看得到，但要是談到在具體的用例中采用異步、無狀態模型，很多人就說“這件事情本質上就是同步的”——真的嗎？ 還是你需要好好換一下思維方式？

7.RDBMS是不足夠的
在服務的世界里，RDBMS并不能適合所有的問題。面向文檔的分布式數據庫（Document Oriented Distributed Databases）試圖解決該問題，并為存儲文檔再提供一種新途徑。CouchDB（以Erlang編寫）正從Alpha階段日漸向前發展。InfoQ找來了Anthony Eden，他正在開發的RDDB用Ruby實現了同樣的概念。

點評：RDBMS的地位難以撼動，但在面對分布式服務的時候，有必要打破一些RDBMS的規條，才能滿足性能和可伸縮性的需求。這又是一次新的嘗試。

8.Duck Typing與協議 vs. 繼承
最近在RubyTalk郵件列表中發生了關于何時使用is_a?以及何時使用respond_to?的爭論。這強調了這樣一種狀況：對象可以都響應同樣的接口，但是卻沒有共同的超類。讓我們來分析下這次爭論，然后看看諸如Smalltalk、Erlang和Scala其他這些編程語言是如何解決的。

點評：最基本的OO概念也會被翻出來“學而時習之”。跨出語言的局限才能把概念的本質看得更清楚一點。

9.依賴注入是否值得？
在博客的世界里進行了一場關于使用依賴注入之優點和缺點的有趣討論。論題是：依賴注入是否真的值得？

點評：用慣用熟的DI，為什么要用它倒成了問題。且不管反方的觀點成不成立，讓我們再想清楚，為什么要用依賴注入——松耦合。

10.預先設計的大架構——過早考慮伸縮性之一例？
請看看博客作者們對“過早考慮可伸縮性”這個問題的回應。問題是——在設計應用程序的時候，應該花多少精力去為伸縮性打基礎？

點評：伸縮性不是優化，它是一項需求，我們從一開始就應該考慮它。 對未來的規模估計不足，那到時候就要返工，可能使業務的發展停滯；如果估計得過分，那又是浪費，而且可能錯失市場時機。理論上是存在一個投入/產出比的拐點，可是它在哪里呢？