我們要追求負責(zé)制度的建立，但是也不要泛化負責(zé)制度，換句話說，我們不要把負責(zé)當作手段，不要把懲罰當作目的。當懲罰發(fā)生時，無論是個人還是企業(yè)，都是輸家。這一點很重要。在理想情況下，為了避免懲罰的發(fā)生，責(zé)任的承擔都應(yīng)該是個人自愿的，都應(yīng)該是在個人衡量自己的業(yè)務(wù)能力和工作目標之后作出的決定。這就像古時候帳中大將請命出戰(zhàn)一樣，當他敗歸本隊之后，一般都是高懸免戰(zhàn)牌，用不著去單挑送死。
大連辦公軟件開發(fā)決策解決方案的數(shù)量，永遠比問題的數(shù)量要多。在大連辦公軟件開發(fā)實踐中，最大的困難往往不是在于尋找問題的解決方案，而是在于選擇最佳的解決方案。選擇就是決策，選擇解決方案的過程，就是軟件決策的過程。 在前一節(jié)中，我們討論了軟件開發(fā)中的負責(zé)制度。很明顯，負責(zé)制度直接決定了軟件決策的方式和效果。這也是我把負責(zé)制度放進軟件實現(xiàn)這一章的原因。 負責(zé)制度，可以還原軟件開發(fā)中的公平和真實，可以為企業(yè)補充富有創(chuàng)造精神的新鮮血液，卻不會為軟件的質(zhì)量
帶來直接的好處。不過，負責(zé)制度對軟件決策有著深刻的影響，而正確有效的軟件決策是保證軟件質(zhì)量的基礎(chǔ)。軟件決策包含了哪些具體的內(nèi)容呢？我們來看一個例子。MFK項目開始了軟件架構(gòu)師根據(jù)項目的要求選擇了軟件的架構(gòu)模式——J2EE架構(gòu)和MVC模式；他選擇WebLogic應(yīng)用服務(wù)器和Oracle數(shù)據(jù)庫；他選擇用PLSQL來實現(xiàn)批處理業(yè)務(wù)；他選擇使用Struts框架；他選擇Hibernate作為OR Mapping的框架；他選擇ACORD標準作為領(lǐng)域模型；他選擇高聚合、低耦合的組件模型作為業(yè)務(wù)實現(xiàn)單元；他選擇JBPM作為工作流平臺；他選擇使用多線程技術(shù)來上傳文檔；他選擇使用Ajax技術(shù)來處理部分頁面內(nèi)容的刷新；他選擇Web前端的實現(xiàn)要兼容主流的瀏覽器；他選擇CAS來實現(xiàn)系統(tǒng)的單點登錄；他選擇Gufw作為Application Layer Firewall；他選擇使用對象引用而不是ID作為參數(shù)；他選擇簡化業(yè)務(wù)層中的隱喻的做法。
每一次選擇就是一次決策。看上去，大連辦公軟件開發(fā)決策活動幾乎遍布在軟件架構(gòu)師的所有工作中。同樣，在程序員的工作中，也有很多需要決策的問題。例如，選擇冒泡算法來完成一次計算，選擇觀察者模式來訂閱分發(fā)的消息。
