《怎樣成爲優秀的軟件架構師》解析 來源：中國錄井網 作者：晏高明
近來讀了一篇《怎樣成爲優秀的軟件模型設計者》的文章，感觸頗深。仔細對比分析，發現原來我自己和周圍的軟件開發人員平常的一些自認爲對的做法，有很多是有問題的。
1.人遠比技術重要
你開發軟件是爲了供別人使用，沒有人使用的軟件只是沒有意義的數據的集合而已。許多在軟件方面很有成就的行家在他們事業的初期卻表現平平，因爲他們那時候將主要精力都集中在技術上。顯然，構件（components），EJB（EnterpriseJavaBeans）和代理（agent）是很有趣的東西。但是對於用戶來說，如果你設計的軟件很難使用或者不能滿足他們的需求，後臺用再好的技術也於事無補。多花點時間到軟件需求和設計一個使用戶能很容易理解的界面上。從微軟操作系統和OFFICE套件在市場上的成功可以得到對這個問題的最佳解釋。
2.理解你要實現的東西
好的軟件設計人員把大多數時間花費在建立系統模型上，偶爾寫一些源代碼，但那隻不過是爲了驗證設計過程中所遇到的問題。這將使他們的設計方案更加可行。有效的系統分析和架構是減少後期錯誤或複雜實現的必要保證。
3.謙虛是必須的品格
你不可能知道一切，你甚至要很努力才能獲得足夠用的知識。軟件開發是一項複雜而艱鉅的工作，因爲軟件開發所用到的工具和技術是在不斷更新的。而且，一個人也不可能瞭解軟件開發的所有過程。在日常生活中你每天接觸到的新鮮事物可能不會太多。但是對於從事軟件開發的人來說，每天可以學習很多新東西（如果願意的話）。目空一切、自滿自足的人是不可能成爲一個優秀的軟件架構師的。
4.需求就是需求
如果你沒有任何需求，你就不要動手開發任何軟件。成功的軟件取決於時間（在用戶要求的時間內完成）、預算和是否滿足用戶的需求。如果你不能確切知道用戶需要的是什麼，或者軟件的需求定義，那麼你的工程註定會失敗。我們進行的很多需求分析，實際上是想當然的認爲用戶的需求和自己認爲的應該是一樣的。
5.需求其實很少改變，改變的是你對需求的理解
需求分析需要一絲不苟、精確的完成,而設計的時候反而可以發揮創造力和想象力。
如果需求經常改動，很可能是你沒有作好需求分析，並不是需求真的改變了。
你可以抱怨用戶不能告訴你他們想得到什麼，但是不要忘記，收集需求信息是你的工作。
需求真正改變的情況很少，但是沒有做好需求分析工作的理由卻很多。
6.經常閱讀
在這個每日都在發生變化的產業中，你不可能在已取得的成就上陶醉太久。
每個月至少讀2、3本專業雜誌或者1本專業書籍。保持不落伍需要付出很多的時間和金錢，但會使你成爲一個很有實力的競爭者。這一條在我周圍能夠真正實現的人很少。
7.降低軟件模塊間的耦合度
高耦合度的系統是很難維護的。一處的修改引起另一處甚至更多處的變動。
你可以通過以下方法降低程序的耦合度：隱藏實現細節，強制構件接口定義，不使用公用數據結構，不讓應用程序直接操作數據庫。
耦合度低的軟件可以很容易被重用、維護和擴充。
8.提高軟件的內聚性
如果一個軟件的模塊只實現一個功能，那麼該模塊具有高內聚性。高內聚性的軟件更容易維護和改進。
判斷一個模塊是否有高的內聚性，看一看你是否能夠用一個簡單的句子描述它的功能就行了。如果你用了一段話或者你需要使用類似“和”、“或”等連詞，則說明你需要將該模塊細化。
只有高內聚性的模塊纔可能被重用。
9.考慮軟件的移植性
移植是軟件開發中一項具體而又實際的工作，不要相信某些軟件工具的廣告宣傳。
即使僅僅對軟件進行常規升級，也要把這看得和向另一個操作系統或數據庫移植一樣重要。
當你使用了某個操作系統的特性，如它的進程間通信(IPC)策略，或用某數據庫專有語言寫了存儲過程。你的軟件和那個特定的產品結合度就已經很高了。
好的軟件設計者把那些特有的實現細節打包隱藏起來，所以，當那些特性該變的時候，你僅僅需要更新那個包就可以了。這些說到容易做到很難，沒有紮實的基本功是很難成功的。
10.接受變化
這是一句老話了：唯一不變的只有變化。
通過在建模期間考慮這些假設的情況，你就有可能開發出足夠強壯且容易維護的軟件。設計強壯的軟件是你最基本的目標。
11.不要低估對軟件規模的需求
Internet帶給我們的最大的教訓是你必須在軟件開發的最初階段就考慮軟件規模的可擴充性。
今天只有100人的部門使用的應用程序，明天可能會被有好幾萬人的組織使用，下月，通過因特網可能會有幾百萬人使用它。
在軟件設計的初期，根據在用例模型中定義的必須支持的基本事務處理，確定軟件的基本功能。然後，在建造系統的時候再逐步加入比較常用的功能。
在設計的開始考慮軟件的規模需求，避免在用戶羣突然增大的情況下，重寫軟件。同時也不能只因爲考慮未知的用戶量而花費太大的成本。需求分析是平衡控制的依據。
12.性能僅僅是很多設計因素之一
關注軟件設計中的一個重要因素--性能，這好象也是用戶最關心的事情。一個性能不佳的軟件將不可避免被重寫。
但是你的設計還必須具有可靠性，可用性，便攜性和可擴展性。你應該在工程開始就應該定義並區分好這些因素，以便在工作中恰當使用。性能可以是，也可以不是優先級最高的因素，我的觀點是，給每個設計因素應有的考慮。花哨的、運行快速但是不能解決用戶問題的系統，是不會得到用戶的滿意的。
13.管理接口
應該在開發階段的早期就定義軟件模塊之間的接口。這有助於開發人員全面理解軟件的設計結構並取得一致意見，讓各模塊開發小組相對獨立的工作。一旦模塊的接口確定之後模塊怎樣實現就不是很重要了。
從根本上說，如果你不能夠定義你的模塊“從外部看上去會是什麼樣子”，你肯定也不清楚模塊內要實現什麼。
14.走近路需要更長的時間
在軟件開發中沒有捷徑可以走。
縮短你的在需求分析上花的時間，結果只能是開發出來的軟件不能滿足用戶的需求，必須被重寫。
在軟件建模上每節省一週，在將來的編碼階段可能會多花幾周時間，因爲你在全面思考之前就動手寫程序。
你爲了節省一天的測試時間而漏掉了一個bug，在將來的維護階段，可能需要花幾周甚至幾個月的時間去修復。與其如此，還不如重新安排一下項目計劃。
避免走捷徑，只做一次但要做對。
15.證明你的設計在實踐中可行
在設計的時候應當先建立一個技術原型，或者稱爲“端到端”原型。以證明你的設計是能夠工作的。
你應該在開發工作的早期做這些事情，因爲，如果軟件的設計方案是不可行的，在編碼實現階段無論採取什麼措施都於事無補。技術原型將證明你的設計的可行性，從而，你的設計將更容易獲得支持。
16.應用已知的模式
目前，我們有大量現成的分析和設計模式以及問題的解決方案可以使用。
一般來說，好的模型設計和開發人員，都會避免重新設計已經成熟的並被廣泛應用的東西。
17.研究每個模型的長處和弱點
目前有很多種類的模型可以使用,如下圖所示。用例捕獲的是系統行爲需求，數據模型則描述支持一個系統運行所需要的數據構成。你可能會試圖在用例中加入實際數據描述，但是，這對開發者不是非常有用。同樣，數據模型對描述軟件需求來說是無用的。每個模型在你建模過程中有其相應的位置，但是，你需要明白在什麼地方，什麼時候使用它們。
18.在現有任務中應用多個模型
當你收集需求的時候，考慮使用樣例模型，用戶界面模型和領域級的類模型。
當你設計軟件的時候，應該考慮製作類模型，順序圖、狀態圖、協作圖和最終的軟件實際物理模型。
程序設計人員應該慢慢意識到，僅僅使用一個模型而實現的軟件要麼不能夠很好地滿足用戶的需求，要麼很難擴展。
19.帶工具的傻瓜還是傻瓜
使用一個很優秀的CASE工具並不能使你成爲一個建模專家，只能使你成爲一個優秀CASE工具的使用者。成爲一個優秀的建模專家需要多年的積累，不會是一週針對某個價值幾千美元工具的培訓。一個優秀的CASE工具是很重要，但你必須學習使用它，並能夠使用它設計它支持的模型。現在的編程工具越來越容易上手，有不少的人已經不去加強對基礎知識的學習，這是很危險的。
20.理解完整的過程
好的設計人員應該理解整個軟件過程，儘管他們可能不是精通全部實現細節。
軟件開發是一個很複雜的過程，除了編程、建模、測試等你擅長工作外，還有很多工作要做。好的設計者需要考慮全局。必須從長遠考慮如何使軟件滿足用戶需要，如何提供維護和技術支持等。
21.常做測試，早做測試
如果測試對你的軟件來說是無所謂的，那麼你的軟件多半也沒什麼必要被開發出來。建立一個技術原型供技術評審使用，以檢驗你的軟件模型。在軟件生命週期中，越晚發現的錯誤越難修改，修改成本越昂貴。儘可能早的做測試是很值得的。測試工作一貫是得不到重視的，即便你天天掛在嘴上，但是請看看你的行動。黑盒測試將壓力給了測試人員，實際上很多的無用測試的根源應該從白盒測試中查找，這是軟件開發人員的問題。
22.把你的工作歸檔
不值得歸檔的工作往往也不值得做。歸檔你的設想，以及根據設想做出的決定；歸檔軟件模型中很重要但不很明顯的部分。給每個模型一些概要描述以使別人很快明白模型所表達的內容。
23.技術會變，基本原理不會
如果有人說“使用某種開發語言、某個工具或某某技術，我們就不需要再做需求分析，建模，編碼或測試”。不要相信，這隻說明他還缺乏經驗。拋開技術和人的因素，實際上軟件開發的基本原理自20世紀70年代以來就沒有改變過。你必須還定義需求，建模，編碼，測試，配置，面對風險，發佈產品，管理工作人員等等。
軟件建模技術是需要多年的實際工作才能完全掌握的。好在我們可以從以上的建議開始，完善自己的軟件開發經驗。
要想成爲優秀的軟件架構師或軟件開發人員，必須要有一個端正的態度，如果只是想依靠這個所謂的名份做幌子、混日子。我勸你還是不要踏入這個行業，以免誤人誤己。
作者簡介：晏高明，中原油田地質錄井處信息管理中心工作，2006年獲國家級“系統分析員”認證資格證書。