第15章 軟件架構(gòu)要引入控制嗎

軟件架構(gòu)向軟件項(xiàng)目引入結(jié)構(gòu)和遠(yuǎn)見，是否也引入了控制？如果答案是肯定的，那控制是好還是壞？

提供指導(dǎo)，追求一致性

很多軟件架構(gòu)的實(shí)踐都會(huì)向軟件項(xiàng)目引入指導(dǎo)和一致性。如果你見過一個(gè)軟件系統(tǒng)內(nèi)的常見問題或橫切關(guān)注點(diǎn)有多種實(shí)現(xiàn)方式，就會(huì)明白為什么這很重要。我想起不少案例。我見過一個(gè)代碼庫里用到了好多個(gè)ORM框架，還有的軟件系統(tǒng)有好幾種跨棧的組建配置方式，有用XML文件的，也有用數(shù)據(jù)庫表的。部署和維護(hù)這些系統(tǒng)太有挑戰(zhàn)性了。

只有引入一定程度的控制和約束，比如，阻止團(tuán)隊(duì)成員偏離正軌，指導(dǎo)和一致性才可能成為現(xiàn)實(shí)。如果你為了滿足一些主要的非功能性需求，專門設(shè)計(jì)了一個(gè)分布式軟件系統(tǒng)，就不能讓人把數(shù)據(jù)庫操作的代碼寫在網(wǎng)頁中。控制也可以只是保證你的代碼庫有一個(gè)清晰一致的結(jié)構(gòu)，以包、命名空間、組件、層等形式合理地組織你的代碼。

控制的程度

真正的問題是需要引入的控制量。一種方法是獨(dú)裁，任何人都不能擅自做決策；另一種方法是放手，沒有人會(huì)得到任何指導(dǎo)。在軟件項(xiàng)目中，這兩種我都見過。我也接手過混亂的項(xiàng)目，每個(gè)人基本上都只管自己的設(shè)備。毫不意外，最后的代碼庫簡直一團(tuán)糟。在這樣的項(xiàng)目中引入控制真是艱苦的工作，如果這個(gè)團(tuán)隊(duì)還打算交付一份令最初推動(dòng)者滿意的軟件，就需要控制。

控制因文化而不同

我也注意到，不同國家和文化對(duì)控制的看法也不盡相同。有些國家（比如英國）就認(rèn)同控制以及它帶來的約束，而另一些（比如斯堪的納維亞地區(qū)的國家）則偏向授權(quán)和主動(dòng)性。舉個(gè)現(xiàn)實(shí)中的例子，就是完全控制軟件項(xiàng)目使用的全部技術(shù)（從編程語言到登錄庫的選擇），還是接受團(tuán)隊(duì)里任何人做的決策。

操縱桿，而非按鈕

我喜歡把控制看作操縱桿，而不是某些非黑即白、只有兩種狀態(tài)的東西。一端是由你獨(dú)裁的方法，另一端則寬松得多。兩者之間你可調(diào)整，這讓你能夠在需要時(shí)引入足夠的控制。那么，你要引入多少控制？我得承認(rèn)，我只能給出一個(gè)咨詢式的回答，在不清楚的情況下，這取決于以下這些事。

? 團(tuán)隊(duì)是否經(jīng)驗(yàn)豐富？

? 團(tuán)隊(duì)以前一起工作過嗎？

? 團(tuán)隊(duì)有多大？

? 項(xiàng)目有多大？

? 項(xiàng)目的需求復(fù)雜嗎？

? 有沒有需要考慮的復(fù)雜的非功能需求或限制？

? 日常的討論是什么樣的？

? 團(tuán)隊(duì)或已有的代碼庫是否看起來已經(jīng)混亂不堪？

? 等等。

我的建議是，先從部分控制開始，傾聽反饋，以便隨著項(xiàng)目的推進(jìn)再微調(diào)。如果團(tuán)隊(duì)老是問“為什么”和“怎么辦”，那可能就需要更多指導(dǎo)。如果團(tuán)隊(duì)好像總是在和你對(duì)著干，可能你就是把操縱桿推得太多了。這沒有一個(gè)標(biāo)準(zhǔn)的答案，但有一些控制是好事，因此很值得花幾分鐘看看你的團(tuán)隊(duì)適合引入多少控制。