BlueDavy之技術Blog

# re: 分層與分模塊開發 2006-03-19 22:31 fisher

很高興又有人對這個問題感興趣了，說說我的看法
任務分解不應該以系統功能為主視角
而是考慮以人為本

任務分解，是一個面向人而不是面向任務的過程
這個問題實際上是對系統橫向切分和縱向切分的問題
很多項目管理方面的書要么對這個問題采用了一種偏致的做法
比如《PMP：Project Management Professional Study Guide》中采用縱向分解方法并羅列了很多好處
而有些書籍則再這個問題上搗漿糊，如WBS在這個問題上羅列出N種方案卻沒給出任何實際意見
且，很多人認為任務分解的終極目標為減少對交流的依賴

在這個問題上，我認為應該以團隊特色設計任務分解方式
而終極目標，則不是減少依賴，而是讓依賴可管理
即軟件結構設計影響任務分解，而任務分解影響組員間的依賴關系
反之，只有符合目前團隊的風格的任務分解才能高效運行，而該任務分解將影響架構師的架構抉擇。其實，這正是XP中團隊設計的根本原因。
這也是軟件項目管理上的一個重大特色，就是軟件結構設計同團隊結構設計的不可分割性。也是軟件開發難以實行工廠化的原因。

如果你在開始就積極的開展設計，并且把設計的過程持續下去，你的任務的劃分就會成為一個縱橫交錯的動態的調整的過程。而應該注意的師，模塊并不是任何任務劃分的一個約束，而只是為不同的人協同書寫相同的模塊提供的一種約束。

而如果以任務為視角，無論橫向分解還是縱向分解，都會在某種情況下陷入困境。
實際上，由于國內目前的軟件項目普遍不大，所以對于交流的有效性的感覺并不強烈
這問題在多個公司合作開發的過程中尤為突出

  回復  更多評論   

# re: 分層與分模塊開發 2006-03-19 23:02 fanta

我的經驗是相反，對于不成熟的團隊，分層可能是災難吧。  回復  更多評論   

# re: 分層與分模塊開發 2006-03-20 09:35 citysir

在保證分層的情況下再分模塊，這有什么問題嗎？  回復  更多評論   

# re: 分層與分模塊開發 2006-03-20 09:35 破門

這個命題我個人認為可能永遠出不了結果，只能以刀劍之爭來比喻一下：究竟是胡家快刀厲害，還是苗家劍法無雙？
事實上，我覺得還是應該就是論事，發揮各自的長處，最終道理都是相通的，就像胡一刀可以和苗人鳳互換兵器，依然要爭個三天三夜還是會旗鼓相當一樣。

說白了點，為了達成目標，你長于架構可以先分層再來支持模塊。如果你長于業務，自然先分模塊再考慮重構系統分層。可嘆的是，我們往往只取其一。做產品的，只管分層，不管應用；做應用的只看模塊，不看架構。最終，都是死路一條！  回復  更多評論   

# re: 分層與分模塊開發 2006-03-20 11:15 小陸

項目的初期，應該用較少的人力，設計開發系統的框架，建立底層的開發平臺。這個時候主要是分層。
當這部分工作完成的差不多了，就可以大批的人上去，開發具體的功能點，直接實現用戶的需求。這個時候主要就是分模塊了，每個功能點都要有直接的負責人。  回復  更多評論   

# re: 分層與分模塊開發 2006-03-21 17:29 guitarpoet

分層開發的最重要的特征是層與層之間的松耦合。松耦合所帶來的結果是，各層之間都可以有自己的基礎模塊，可以實現本層內部的重用，在底層發生變化的時候（變化協議、變化技術、甚至變化介質），上面的層是可以花費很小的成本進行適應的（比如操作系統和應用程序層）。

商業開發必須考慮開放成本，而有效的重用是降低成本的方法之一。

模塊化開發，估計每家做企業級應用的公司都必然會采用這個方式。拿用電系統來說，客戶服務模塊和電費管理模塊業務差距非常大，非業務專精人員，很難在短時間內寫出高效和高質量的代碼（光是業內常識就有的學的，而且各處業務還都不大相同）。

fanta的話是有問題的，對于不成熟的團隊，如果沒有成熟的技術框架進行支持和有能力的項目負責人進行管理的話，生產的軟件產品質量和工期就沒有辦法得到有效的保證。  回復  更多評論   

# re: 分層與分模塊開發 2006-03-21 17:46 guitarpoet

@fisher

軟件開發必須以人為本，但是所謂的“團隊特色”是一個偽命題，團隊中的人總會流失（升遷、跳槽、借調），總會有新的人加入，這是業內的常識。如果針對團隊作出良好設計的人或是一個對各種技術十分精通的人被別的公司高薪翹走了，怎么辦？

合格的軟件公司都要有一定的應急機制，這也是對軟件質量保證的手段之一。這樣就不會因為某一個開發人員跳槽而造成手足無措的情況。

怎樣才能 達到這一點？那就是有效的分層，有效的把損失局限在某一個范圍內，就算是臨時拿新人頂，他也可以迅速的接替流失人員的位置。

當然，Brooks說過：“無論怎樣，項目肯定會延期”。但是要要盡最大可能的把損失降到最小。

太多的軟件工程書不顧現實的情況了，完美的人是不存在的，技術全才一般是不愿意只做技術的（這個東西真是有趣啊），我們得面對現實。  回復  更多評論   

# re: 分層與分模塊開發 2006-03-21 20:22 fisher

@guitarpoet

首先
以人為本!=團隊特色
任何團隊都會有特色，但不是任何團隊的開發過程都以人為本
所以，你說的顯然是個偽命題

另外，如果某一開發人員的離開對你的團隊和公司有如此打擊，只能是項目經理失職
同任務分解和任務分配的原理沒有任何關系

還有，你提到的例子中，混淆了模塊和模塊劃分的區別
我前面說過，模塊并不是任何任務劃分的一個約束，而只是為不同的人協同書寫相同的模塊提供的一種約束。
而模塊劃分，則既不是業務問題，也不是技術問題，它受到實現技術、任務和人員配置的三角關系的約束。
所以，在架構及開發任務分解這方面，沒有萬試萬靈的靈丹妙藥，最重要的是如何管理依賴，所有的依賴。所以，從技術上來說，其重點在于，架構師和項目管理者對有影響力的各個方面的動態依賴的認識及協調能力。  回復  更多評論   

# re: 分層與分模塊開發 2006-03-21 21:22 BlueDavy

^_^，好多評論..

軟件過程以及開發方式都是為了降低人的因素來實現項目的可控性。
雖然這點一定程度上來說已經在強調不是以人為本的問題......
分層和分模塊開發，一個實際的不同的例子就是當運用在一個水平相差很大的團隊中的時候，分模塊很容易造成模塊的質量上難以保證的問題，分層則一方面可以保證這問題，另一方面可以發揮團隊中各人特長，同時對于團隊成員的培養也是有很大的好處的。
當然，我的意思不是說分層的開發方式就一定更好，就像破門所說，這個是劍刀之爭，需要根據不同的情況做出不同的選擇..
或者可以去好好的總結什么樣的情況下適合分層開發方式，什么樣的情況下更適合采用分模塊開發的方式  回復  更多評論   

# re: 分層與分模塊開發 2006-03-21 23:05 fisher

@BlueDavy

似乎我說的太多了:)
因為我對這個問題真的感興趣
也多次與人交流，在實踐中，我發現無論哪種方法都會有問題

你說“軟件過程以及開發方式都是為了降低人的因素來實現項目的可控性。”
我認為這是不對的，從管理學角度來講，管理的目標是建立行為規范
而行為規范是用來規范人，而不是用來規范過程的

我發現技術人員總是認為以人為本是個討巧的話題
其實正相反，在團隊管理中，用人絕對是一個技術活
是要通過分析得出正確結論的。這需要理論、模型、計算以及權衡裁決
其實跟軟件設計是一回事，這也是為什么管理學到最后也是數學的原因
管理不是感覺、而是技術和數學

anyway，說回分層的話題
無論分層還是分模塊，你都會依賴你的團隊來完成
而無論分層還是分模塊，都會有不同的依賴模型
不知道我這么說是不是很掃大家的興^_^
但我還是那句話：從技術上來說，其重點在于，架構師和項目管理者對有影響力的各個方面的動態依賴的識別及協調能力。

ps.
恰巧，本人目前正在運行中的兩個項目
一個是分模塊開發，一個是分層開發的。
  回復  更多評論   

# re: 分層與分模塊開發 2006-03-22 09:04 guitarpoet

@fisher

也許我們的想法相似，只是表達方式上有所不同。在IT行業，熟練的團隊的工作效率是要比非熟練的團隊的工作效率高數十倍甚至上百倍的。

但是，別忘了，良好的分層架構、模塊封裝使得可以充分利用社會分工機制（開源組織、組件和工具供應商）對工作效率的提高也是數十倍甚至上百倍的（而且更可靠）。

JavaEE就是這么一個分層的概念。

管理是一門藝術，涉及到的地方就比較多了。改天我們再對它進行探討（郵件的方式最好）。現在要探討的是技術架構上的問題。

哪個成熟的軟件公司沒有自己的軟件開發過程？沒有自己的基礎軟件開發架構體系？沒有自己的技術價值觀？

沒有這些東西，談什么公司開發文化都是妄談。  回復  更多評論   

# re: 分層與分模塊開發 2006-03-22 10:46 破門

@fisher
“在實踐中，我發現無論哪種方法都會有問題”，完全同意！：）
因為實踐中沒有哪一個項目是完全相同的，所以我說，分層與分模塊只是技術，不要把它們當做“銀彈”。
實踐是門更深的藝術！
所以，選擇技術架構、路線和管理手段的方法完完全全來自你面臨的實際情況，你的項目目標，你能找到的資源，你所在的管理環境等等.....
因此，討論任何一門技術方法的時候，不能只討論技術本身，千萬不要忘記了它們適用的場景，否則，太容易帶來誤導了。  回復  更多評論   

# re: 分層與分模塊開發 2006-03-22 12:39 BlueDavy

@fisher

^_^，覺得你誤解了我所說的
"軟件過程以及開發方式都是為了降低人的因素來實現項目的可控性。"
這句話所表達的觀點和你所說的
"行為規范是用來規范人，而不是用來規范過程的"
是一個意思，都是為了降低人的因素造成對項目的影響。

呵呵，比較想知道你現在分層和分模塊開發的兩個項目目前進展來看，你覺得兩者更為適合的場景是？  回復  更多評論   

# re: 分層與分模塊開發 2006-03-23 13:25 fisher

忙里偷閑上來看看^_^
接jerry的話，我也會來說說我的項目的情況

其實我覺得分層或分模塊的說法并不準確
何謂分層？何謂分模塊呢？

咱們先繞開這個容易引發爭論的定義，來說說實際情況
在J2EE應用中，似乎分層是很自然的想法
簡單的說，我們要分：表現層、邏輯層、持久層
然后分模塊，則是一個人負責一個功能模塊，貫穿所有層

現在，我們來跳出J2EE領域，看看軟件開發其他領域是什么樣的
比如，一個電信基礎業務系統開發
我們假設，包括語音平臺、帳務平臺、后臺主機系統、前端接入系統、計費平臺、業務管理平臺等
在系統設計中，我們分為語音模塊開發、帳務系統模塊開發、主機通訊系統開發、前端接入系統開發、計費及業務管理系統開發
那么這是分層還是分模塊呢？
顯然，一個人做一個業務的全套處理是不可能的（我很想結識能做到的xd），所以，這不會是分模塊開發。
如果說是分層，那么邏輯層在哪里？持久層在哪里？另外的問題是主機通訊系統將會貫穿始終，這應該算哪一層？并且帳務處理會使所有層的數據產生強烈耦合。

同樣的問題，出現在銀行綜合業務處理系統
一個銀行綜合業務處理系統中，我們分為主機系統、主機客戶帳分錄系統、IBS系統、柜面系統、電話銀行接入模塊、ATM系統及接入模塊、網銀系統及接入端點模塊
下面我們來分一下層，按照J2EE的慣例，我們分為表現層、邏輯層和持久層
首先表現層為所有接入模塊及柜面系統、邏輯層是什么呢？IBS？客戶帳系統？還是主機系統？那么持久層呢？按照銀行開發的情況，一般來說，數據分別存儲在Host，客戶帳系統、IBS和網銀上。那么我們顯然不能夠分層開發
那么所謂分模塊呢？哦....我還無緣得識這樣的朋友

所以說，分層還是分模塊，不過是J2EE中的一個idiom
從軟件開發出現到現在，軟件開發的重點仍然是依賴管理，清晰的接口（無論是java中的interface還是c中的.h文件）使得子系統（無論是一個模塊還是一段代碼）的開發人員可以只依賴與接口編程，這才是團隊開發的重點，如果你沒有接口，你就要管理開發人員之間的依賴，如果你有接口，你就要管理接口兩端的依賴。總要有個合作工作的基礎，我們才能繼續前進。

在這點上，似乎英文使用者就不會產生混淆，因為interface這個單詞代表了所能表示的所有交界處。而中文，我們有人機界面、接口、交互、分界面、接觸面等N種解釋

用J2EE的眼光看軟件開發，自然什么都要套到J2EE的模子里去
簡單的說，手里那個錘子，看什么都像釘子：）

我在上面所說的分層、分模塊開發的兩個項目，都是部分分層、部分分模塊的情況，如同我前面所說，是一個縱橫交錯的動態調整過程。
分層，也就是說的那個J2EE項目是在大原則是分層的情況下，實際開發中做了許多調整，項目做到最后，也不能說是分層還是分模塊了：），把一個人硬按在一個位置上，他是不會產生高效的
而另外一個，則是一個銀行綜合業務處理系統。  回復  更多評論   

# re: 分層與分模塊開發 2006-03-23 16:28 guitarpoet

@fisher

其實你混淆了分層的概念，分層開發就不能分模塊了？

分層開發是一種開發方式，目前而言，這種開發方式是非常適合企業級應用的。

但是，它并不與分模塊的開發方式互相矛盾。你把系統根據業務分成相應的模塊以后，還
可以根據需要進行分層開發的。這同樣可以體現出分而治之的原則。

對于公司而言，應該有一個開發人員遵循的統一標準，然后這一個標準還要根據工程和業務模塊的需要進行相應的剪裁，你總不希望各個工程和各個模塊之間開發沒有相同點，開發方式各有不同吧，如果真是那樣，你怎么實現項目之間人員的調換？你不能實現人員的調換，怎么保證項目一定可以如期完成？

分模塊是必須的，但是應該建立在良好的分層的基礎上，否則軟件質量的管理不可能達到公司的級別，只能依賴個別優秀的軟件開發管理人員和項目架構師，這對一個公司是有風險的。

JavaEE之所以流行就是因為它不是簡單的工程師文化，它代表了商業開發的概念和標準，相對而言.NET的工程師文化可能更強一些，但是它們是典型的騎墻派（沒有貶義），從C#語言的頻繁變化就可以看出來了。

工程師更喜歡概念上的東西，但概念不等同于商業。  回復  更多評論   

# re: 分層與分模塊開發 2006-03-23 23:03 fisher

@ guitarpoet

我的意思是說，不要拘泥于分層開發還是分模塊開發
而是要認清為什么要分層，為什么要分模塊，有什么好處，有什么弊端
以前有人問我某個設計該怎么分層，我說，理解為什么要分層就知道該怎么分層了
不要為了分層而分層
況且，分層不足以描述軟件開發的根本問題，它只是解決根本問題的表現手法之一
這我在前面已經說過了
  回復  更多評論   

# re: 分層與分模塊開發 2006-03-24 08:34 guitarpoet

@fisher

其實我們的想法相似，只是表達方式上有所不同，呵呵。

很高興能跟你討論問題，軟件工程作為一門學科，現在離真正的成熟期還遠，在一定的時間內，概念的爭論是免不了的。

我覺得，在這種條件下，要想真正意義上的進行企業級應用開發，必須腳踏實地的采用注重實效的方法。

而且軟件開發還是要以人（客戶、開發人員）為本的，不管采用什么概念、技術和實現方法。

很多人都喜歡拿企業級應用類比汽車產業，其實可比性沒有想象中那么高，軟件開發畢竟是一個概念上的東西，與現實中的物質相比，它跟人的思想和人分析問題解決問題的方法更近一些。

古希臘的時候，人就開始對自身的概念和思維的邏輯進行探討，但是直到現在，還是沒有什么有突破意義的結果。

軟件開發更接近于哲學，這就是為什么編程高手一般都非常喜歡古典哲學。

其實，技術哲學也是哲學的一種啊。

計算機科學的發展，最后應該是跟人類的哲學的發展相互依存的。

馬克思說的真他媽有道理。  回復  更多評論   

# re: 分層與分模塊開發 2006-03-24 11:58 pb

我理解，在目前的中等團隊—— 20人左右——情況下，對于一個超過20*60人天的項目，分層+分模塊
分層：對于這樣一個項目，必然會有其技術要求，會抽取出來很多通用的、底層的、全面的功能或者服務出來；那么，對于這些部分，技術要求比較高，設計上也許要更多的通用和健康，所以需要幾個高手來把握
分模塊：在此基礎上，根據業務功能模塊分成若干小組進行業務層面的開發。這里，對于技術的要求比較不苛刻，大部分人可以勝任
如果在此基礎上，還有富裕的人力 —— 可能是工作量上的富余 —— 可以把界面和業務層也分開

總之，希望是一個金字塔的形狀  回復  更多評論   

# re: 分層與分模塊開發 2006-03-25 18:47 fisher

@guitarpoet

^_^  回復  更多評論   

# re: 分層與分模塊開發 2006-12-07 15:05 eddy

看到大家談得這么投機,我也上來說兩句!
我個人是偏向分層開發的,但并不是說分層開發一定比分模塊開發好,就好比OOP,AOP一樣,它們都是各有優缺,其實也不是優缺,只是具體使用那種開發方式要根據多個方面來決定,第一:項目需求,第二:人員配備;第三:團隊.

首先,從項目需求來說,要是一個小項目,完成就好,基本不要維護,那么建議用分層開發,反之,如果是一個銀行,電信核心系統.它在設計的時候都不知道會被什么人使用.必須提供完善的接口規范,那么建議使用分層開發,保證面向接口編程,為重構提供可能!
其次,說到人員配置,如果team中每個人都是junior developer,不能提供出成熟的設計,那么建議使用分模塊開發!因為分層開發對系統框架設計的要求比分模塊開發要高!如果team中有幾個設計方面的告訴,能夠保證系統設計的成熟,穩定性,那么分層開發是必然的選擇,何必放著這些高手不用!讓他們做junior都能做的事呢?
最后,說一下團隊,從團隊穩定性的角度,我建議使用分層開發,原因有二,第一,分層保證多人(大于2人)了解同一個模塊,即使走一人,其它了解這個模塊的人也可用接上手;第二,人盡其才,從古到今,都是這個理!

順便引用網絡的上一段話,我覺得挺在理!
"大家不妨想一下，微軟自帶的例子，都是分三層，四層的，這意味著什么？好處肯定是有的，否則就不會帶這個DEMO給全世界用.NET的IT人員參考啦,就不會放在MSDN中！"  回復  更多評論   

# re: 分層與分模塊開發 2007-03-23 15:41 ramon

好久以來我一直都在考慮層與模塊的關系，但是從來沒有把它們和項目管理掛起來， 我一直覺得它們是屬于系統架構設計中的概念， 所有就老糾纏在到底是層包含模塊， 還是模塊包含層這樣的問題中，困惑了許久，今天看到大家的討論，獲益匪淺， 層應該是從架構設計的角度來看 ，是對系統的縱向分解，而模塊應該是從功能呢個角度劃分，是對系統的橫向分解。 模塊與層應該是一個垂直正交的關系。
那么在實際中，我覺得分層加分模塊比較合適， 比如在一個較大的項目中，定義了表示層，邏輯層和持久層， 我可能愿意只在邏輯層和持久層分模塊，表示層可能就交個一個專門的team來開發，必經表示層的開發和后端的開發需要的技術知識領域是有差異的。。。呵呵，隨便說說，歡迎大家指正。 因為這個問題實在困惑我很久，又找不到什么資料， 不知道有沒有朋友介紹一些其他的關于這方面的經典文章。  回復  更多評論   

# re: 分層與分模塊開發 2007-05-24 15:04 jallock17@126.com

看看上面大家的發言，確實是些強人。
那我就我的想法說說：
不管你采用哪種方式開發，都應當基于人（用戶、開發人員、管理人員）,然后綜合考慮項目因素。具體一點說：
我認為，我們大部分開發人員老是基于自身的角度去想應該怎么開發合理，
如果我們換個角度去想想：項目時間不足夠，項目資金不足夠、沒有足夠的需求調研、市場因素等綜合考慮，你會發現有很多問題我們開發人員太過理想化。  回復  更多評論   

# re: 分層與分模塊開發 2007-05-24 15:24 jallock17@126.com

軟件工程，流程的開發方式，都是前人的經驗總結，
需要根據實際情況來結合自身實際條件來找到一條
適合自己的路子才是最可行的  回復  更多評論   

# re: 分層與分模塊開發[未登錄] 2007-06-05 17:16 Marine

不懂J2EE
不過分層了，再分模塊不好么？個人感覺模塊是在層次之下的。每一層有自己的模塊。  回復  更多評論   

# re: 分層與分模塊開發 2007-12-06 15:45 huangyifu

我的經驗是:
分模塊開發速度快些
分層開打質量高一些  回復  更多評論   

# re: 分層與分模塊開發 2009-07-30 16:23 eric土人

讀這位fisher寫的東西真是拗口,是不是能按照主謂賓的結構來排排語法,只表達一個觀點--對敏捷里面提及的團隊合作,在中國,很成問題.  回復  更多評論