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

社區(qū)

Architecture

主題

InfoQ聲明

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

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

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

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

點評：DSL離“領(lǐng)域?qū)＜艺f的語言”還很遠，“讓領(lǐng)域?qū)＜胰ゾ幊?#8221;已經(jīng)基本被MDA、BPM的實踐所否定。不過，我們已經(jīng)從為工作選擇合適的工具、框架，進步到了為工作選擇合適的語言，不管OOP、AOP、FP……通通為我所用。再說，XML配置、連貫接口這些不是很像語言的DSL，我們已經(jīng)用很久了吧。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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