每一項行動都是戰(zhàn)役決策者根據(jù)戰(zhàn)場上瞬息萬變的情況做出的決定。有時候，影響戰(zhàn)役格局的可能只是一個看似微不足道的細節(jié)，例如，準確的情報或者無法預報的惡劣天氣。采購協(xié)同軟件開發(fā)架構(gòu)也是如此。在構(gòu)架軟件系統(tǒng)時，一個細節(jié)上的失誤，可能會導致巨大的軟件開發(fā)成本。我見過這樣一個故事：在一個持續(xù)型的大型項目中，一位軟件架構(gòu)師，為了模塊之間的解耦，決定使用ID作為模塊接口的參數(shù)。他希望所有的模塊，以最保守的方式封閉自己，甚至不愿意公布這些模塊所使用的對象模型?；谶@個想法，一個長整型看上去很理想。
于是他這樣做了，而且還把這一原則推廣到任何需要解耦的地方。結(jié)果呢？由于這些參數(shù)，必須要訪問數(shù)據(jù)庫才能獲取相應的信息，隨著采購協(xié)同軟件開發(fā)系統(tǒng)規(guī)模的不斷增長，一個業(yè)務操作竟然產(chǎn)生了成百上千次的數(shù)據(jù)訪問。這意味著什么呢？意味著系統(tǒng)的性能將急劇下降，意味著性能調(diào)優(yōu)的巨大開銷，意味著升級的困難，意味著模型之間溝通和轉(zhuǎn)換的不便。
所以，使用ID來解耦，是一個設計上的失誤。類似的設計失誤在風險管控軟件開發(fā)架構(gòu)設計中數(shù)不勝數(shù)而這些失誤，對于軟件開發(fā)的影響是非常巨大的。因此我的想法是，一個成功的采購協(xié)同軟件開發(fā)架構(gòu)師應該像戰(zhàn)役指揮官一樣，善于用自己豐富的經(jīng)驗來規(guī)避一切后果嚴重的錯誤決策。
你也許要問，誰才能知道哪些設計是錯誤決策呢？要避免這樣的錯誤發(fā)生，是否要靠一個決策委員會來投票表決呢？相信我，這些疑問是真實存在的。事實上，很多軟件組織的高層管理人員都這么想。這些承擔著經(jīng)營風險的管理者，遭受過一次或多次不成功的項目。他們聽到過來自各方的很多抱怨，他們知道問題出在軟件架構(gòu)上，可是，他們不知道該信任誰。在迷惘中，這些管理者不再尊重某一個人，而是寄望于一個團隊來決策。這不是一個好的想法，問題因此變得更加嚴重。在第5章中，我們會詳細討論這個話題。在我看來，架構(gòu)設計是軟件開發(fā)中最有趣的工作。這項工作，需要的形象思維能力多過邏輯思維能力，需要的激進創(chuàng)新能力多過循規(guī)蹈矩。
