關於軟體工程的一些觀點

目前國內的軟體方面的人才開始大量的關注軟體工程這門學科，大有80年代末90年代初國人追捧漢字系統的勁頭，但是實事求是的理解國內的開發過程，我認為軟體工程固然是一個方面（甚至可能是非常重要的一面），但隱藏在表象後的問題也是不容忽視的，我認為目前開發環節中存在著一些問題或理解的偏差，其中典型的表現在：

1、 學而優則士

這個問題很普遍，很多人都是這樣想：開發到35歲以後就應該考慮管理的問題了。這個想法是“學而優則士”的想法，好的開發人員，不一定是好的管理員，因為側重的面不一樣，知識結構也不一樣。但是，由於很傳統的思想，認為領導就是應該各方面都好些，所以強把“學”推為“士”。這樣不但沒有更好的提高效率，反而浪費了很好的人才。同時，也是由於傳統的思想，“士”更受人尊敬，而“學”往往被認為是藍領，所以很多的“學而優”者也就有成為“士”的激勵誘因了。我認為，這是一個不正常的現象。“學而優”的地位及受人尊敬應該有相應的評判機制，比如說：系統設計師應該比專案經理更加受人尊敬。也只有這樣，“學”者才可以安心設計，“士”者也可以更好發揮“士”的職能。

2、過程與階段

只有過程沒有階段是沒有意義的，我們都知道，任何一個軟體產品的開發是需要很長時間的開發過程的，這個過程也是充滿風險的，如果沒有有效把過程細化，只是簡單的嚴格的按照需求、設計、開發、編碼、測試的流程去做，問題也就蘊含其中了。必須明確的是沒有絕對成功的軟體工程，也沒有滿足一切情況下的絕對的開發過程，將過程階段化只是將風險降低，將蛋糕切細，一次吃不了多次吃。這個在軟體工程中的相應的解決方案是裡程碑。在絕大多數的開發過程中，裡程碑的作用是非常重要的。在有些開發過程中講究的是漸進式的開發，螺旋式的過程，其實也是對裡程碑的一種擴充而已，只不過這些開發過程的裡程碑是定義在自己的開發過程中而已。
好的開發過程應該是在風險管理上的盡量靈活，我不贊成將裡程碑式的階段管理放入到開發過程中的明細規定中，而是應該在不同的產品或項目開發上靈活掌握。有時一個裡程碑可能只是在需求分析階段的初期，但是如果符合實際的開發的需要，我認為就是好的開發方法。用這種觀點觀察RUP，我認為RUP中關於裡程碑的定義有些刻板，RUP基本上是一個演化式的開發方法，演化的層次很清楚，但是，對於實際的開發中的裡程碑定義的靈活性表現的不夠充分。當然，任何開發方法不可能滿足所有要求，在相對固定的需求的項目上，RUP還是有很大的長處的。在這一點上，我比較偏向於MSF的開發方法。

3、軟體工程的左與右

以前學馬列的時候學了一個概念，就是左傾與右傾，好像是這樣定義的：左傾是指的把將來的事現在做，右傾指的事把過去的事現在做。這兩種都是不好的。實事求是的講，我認為現在的推崇RUP、CMM等有些左傾的味道。從管理的角度來講，管理有三個階段：能人管理、制度管理、標準管理。我認為RUP、CMM等屬於標準管理的範疇。現階段很多的公司的能人管理還沒有做好，就急於開展標準管理不是正確的方向。首先將能人管理方式進化到制度管理才是當務之急。所謂制度管理就是建立符合公司實際的規章制度，做到人盡其才，在一個遊戲規則下做事，這樣就可以很大的提高工作效率，更好的溝通開發中的方方面面問題。也只有這樣，才能更加深刻的理解標準管理的重要。越過這個階段，直接跳向更高層次，就象在現階段實現共產主義的想法一樣，有些不切實際。當然，少數公司的制度管理已經很好了，工作效率確實很高了，那就另當別論了。

4、缺少什麼樣的人才

記得一個笑話說：外國人搞軟體工程是在一個黑屋子裡面抓黑貓，不過到現在還是沒有抓住，而中國人是在一個黑屋子裡面，而裡面連貓都沒有，然後有人說，我已經抓到貓了。這個笑話一方面是說明直到現在，軟體工程還是一個在繼續探索、發展的過程，另一個側面也說明中國搞軟體工程摸不著邊的局面。（以上摘自《我有一個夢》，作者：胡朝暉，詳細參見ChinaByte.com）

那麼中國最缺少什麼樣的人才呢？我認為是系統構架師。很多人會說：我們缺少軟體工程人員、缺少良好的專案經理、缺少……，是的，這些人我們確實也缺，但最重要的是系統設計師。因為，無論是專案經理、精通軟體工程的人員，我們都可以培養，相對的培養成本也不是很高，而系統構架師卻需要多年的行業經驗和高超的設計水平，這些都不可能短時間內得到。

很多人說，我們的項目大多都是低成本的包工頭似的項目，但是大家是否想過，如果，真的有一個項目是讓大家去完成很尖深的系統，又有幾個公司可以勝任？！為什麼很多的Open Source的系統可以做的很大，不是因為這些Open Source有多麼的軟體工程，只是由於有一些優秀的系統設計師在參與設計而已。軟體工程只能使得可以做到的工作做的更好，不能解決連做都做不出來的工作。這也可以說明為什麼商業軟體中軟體工程的重要性，其原因很簡單：在大家都能做到的情況下，就要比較誰的作的更好了。

軟體工程是貼在樓房上的馬賽克，有了當然更好，但是如果樓房的結構不好，貼在多的馬賽克也可能只是金玉其外、敗絮其中。

5、對程式員的正常理解

程式員是要求有創造性的，幾乎每個人都是這樣想。但在實際的情況下，又有很多人開始談論如何將程式員當作運轉機器的一個齒輪！這是很不對的，是對軟體工程的一個曲解！首先，程式員不是打字員，程式員之所以重要，在於他的腦袋而不是他的鍵盤。程式員又不是設計師，這就不要求他有宏觀的觀點。程式員是要求對某個方面非常的精通的，哪怕是很小的一部分。系統設計師不可能將設計做到可以編程式的地步，他需要把握的是整體。而相對的，程式員需要把握的是局部。當然，如果任何局部都做的很好，整體不一定好，反之也一樣。就想一條船，設計師是舵手，他需要有宏觀的能力、需要知道那有險灘、需要辟其風險，而程式員是劃手，他需要做到和大家行動一致、需要使用最佳的划船姿勢、需要有吃苦耐勞的精神。

不要認為程式員是機器，在他的崗位上一樣可以知道船航行的軌跡，要仔細聽取他們的建議，因為，有時航行的問題往往都是先被划船的人發現的。

6、討論的也需一定的標準

有時候會有這樣的問題：一幫市場人員與一幫技術人員討論，為了要解決市場與技術的協調問題，其中市場人員說市場的問題，技術人員說技術的問題，結果往往公說公有理、婆說婆有理。所以，討論的也需一定的標準！如何定義這個標準在不同的場合和環境下是不盡相同的。技術人員最終需要解決市場上的問題，可是解決的方法並不是簡單的服從。如果那樣，是不可能做出真正符合市場的產品，因為市場人員看到的只是一定階段的市場表象，他們並不清除這裡面的原因，也不清楚原因的本質。

比如說：比如說現在人們常說的3層結構，往往客戶需要讓你使用3層結構的思路去解決實際的問題，可是他們並不清除為什麼，只是認為很多人都是這樣的做的。我不是否定3層結構的優點，只是說，在很多的項目中並不一定要求使用3層結構，因為那會使複雜度增加，而靈活性的掌握又需要很多客戶的支援（客戶的很明確的說明商務邏輯），同時，真正發揮3層結構的好處，還需要很強的設計師的良好的設計。在很多的小項目中完全沒有必要多此一舉，把兩層的問題3層化。

建立這個討論的標準就要求，技術人員理解問題的緣由，清楚問題的實質。我說的意思並不是要求技術人員要有很強的市場的眼光，而是需要把這些更深層次的原因及時的說明給市場人員聽。

簡單的服從市場人員的意志往往是項目可控性失敗的直接原因。

7、片面的理解管理學；

現在有一股勢頭認為，軟體工程中的管理者只要拿個手冊照搬執行，肯定10有8、9不會有大的問題。但是問題真是這樣嗎？在《軟體工程—實踐者的研究方法》中有這樣一段關於管理者的神話：
神話：我們已經有了關於建造軟體的標準和規程的書籍，難道它們不能給人們提供所有其需要知道的資訊嗎？
事實：不錯關於標準的書籍已經存在，但真正用到了它們嗎？……它們完整嗎？很多情況下，對於這些問題的答案均是“不”。（P.11）
我們必須明確管理的責任、實質與優劣。優秀的管理是無為管理，管理的目標就是不管理。不管的前提是有一套符合實際的遊戲規則，大家按照遊戲規則做遊戲。有些人理解管理就是天天跟到被管理者的後面，不定的催促、不停的調度。這是不對的，這樣的管理者是妨礙了正常的工作，是對管理的曲解。
所以說，優秀管理的前提是建立一套大家都能遵守的有效遊戲規則，在此規則下，達到生產力的目的。
那種認為管理就是找人談話、挑人問題、催促進度的理解是錯誤的，如果，真的遇到了這樣的問題，我認為那確實是需要重新審視一下自己定義的規則的時候了。

8、您有一個持續發展的架構嗎？

明知不可為而為之的後果是怎樣的呢？可能是這樣的：項目進度太緊、產品問題很多、每天陷入到工期的泥潭之中……。很多人說項目太緊是市場的時間給的太緊、是專案計劃不嚴密、是軟體工程不到位等等，但是，回頭想想，如果真的做到了：市場的時間給的充分、專案計劃嚴密、軟體工程符合實際，那麼，您有把握完成一個符合使用者實際需要的、優秀的、低維護的項目嗎？我認為，還不行。
可能很多人不會反對，如果客戶的要求是讓我們做一些Word、PowerPoint的模板（無需編寫很多的代碼），我們可以很容易的滿足客戶的需求。但是，如果客戶讓我們做一些關於MIS、POS、甚或是如教育、政務等軟體，我們的成功的把握度就大大降低了。為什麼呢？如果，我們做其他類的軟體如同做Word的模板一樣容易的話，我們還會沒有把握嗎？我們缺什麼呢？我們在做這些軟體的時候為什麼就有些信心不足呢？
問題的癥結在於：您是否有一個持續發展的架構。您如果有一個基本滿足使用者需要的semi-application的話，您將不會遇到那些問題。
如果您在實際工作中屢戰屢敗又屢敗屢戰的時候，您會不會問自己這樣一個問題：您有一個持續發展的架構嗎？

9、對過程範型的誤解；

任何過程範型都有它的優點和缺點。我們不能否定瀑布模型的優點也不能否認其缺點，我們不能否定演化模型的優點同時也不能否認其缺點，其他範型也一樣。很多人推崇RUP、XP等過程範型，但是前提是我們必須知道這樣的模型是演化模型，有很多的優點，同時也不可避免的有其缺點的存在。
比如說：我們需要做一個需求很明確，並且在一段時間內需求不易改變的項目的時候，如：一個資料結構類庫、一個通訊底層庫等，這時候，使用瀑布模型可能會得到更好的效果。為什麼呢？首先，演化模型的任何一次跌代的終點就是下一次跌代的起點，這樣有助於使用者更好的把握系統，可以更好的理解需求，但這種模型並不適合需求非常清晰的情況，如果需求非常清晰，這種跌代只能更多的產生冗餘的文檔，更可能產生很多過渡的設計，而這些顯然是一種浪費。有些人，乾脆就把演化模型當作瀑布模型來使用，講究的是一步到位，這種做法就更有問題了！
如果需要一步到位的系統（即需求非常明確，同時需求很少改變），演化就變成了瀑布，這時候提倡演化無非就是多走了幾個彎路而已。

正確的理解過程範型是正確的使用過程範型的前提。

10、對測試工作的誤解；

我們應該重視測試工作，但是，過度的重視測試又會產生嚴重的問題。測試工作最重要的是要發現問題，是保證提交給客戶的軟體中不再出現問題，從這個觀點說，測試很重要，但是，我們不能因為測試而測試，很多問題不是能夠通過測試而解決的。
發現問題的時候解決是對的，正如亡羊補牢，未為晚已。但是對於問題的源頭我們需要更加的重視。我們更加需要重視對於需求分析的審核、對於設計的複審、對於代碼的複審。將問題消滅在搖籃中，總比與問題搏鬥來的容易。
對軟體的測試固然重要（無論是單元測試還是系統測試），但這種只對產生了問題徵兆的測試是一種狹義的測試。我們決不能忽略對需求分析的測試（需求複審）、對設計的測試（設計評測），這樣的種種測試的綜合，才是軟體工程中對測試的廣義理解。
如果，您發現在工作中測試的環節上發現了太多的問題，您就是真正應該考慮在其他環節上“測試”是否出了問題的時候了。有時候，羊亡的太多，補牢也就晚了。

測試在軟體工程中是一個狹義的概念，但是我們應該努力廣義的去理解。

11、對文檔作用的錯誤理解；

文檔在開發過程中是很有用的，但文檔泛濫就不好了。有些人說，開發過程中文檔越多越好，我認為這種觀點是不對的。首先我們要明確開發過程中為什麼要寫文檔，文檔的最根本的作用是為了溝通！一個項目或產品可能需要延續很長的時間，開發過程中可能需要很多的環節，可能會遇到很多的問題和很多的解決的方法，這時，我們需要文檔的協助，我們需要有一個記錄，我們需要有一個共同的聲音。文檔不過是一個準繩，將開發中的各個樹枝樹葉扶正。如果，這個準繩太多太緊，大樹可能會發育的很高很直，但是就是有些畸形，如果這個準繩太少太松，大樹可能就會變成灌木叢。文檔的多少、繁簡是有度的，絕對不能說越多越好。
那麼這個度是多少最好呢？我覺得有幾個標準：1、文檔需要說明解決問題的方法而不是解決問題的理論；因為解決問題的理論是在文檔形成中做到的。2、文檔完整即可，每一份文檔說明一個問題，無需將多個文檔的內容放在一個文檔的裡面；3、除了重要階段形成文檔，其它部分都只是討論或者說是想法（這些通過其它工具可以有效管理起來）；4、不要讓文檔成為累贅，如果真是這樣，我認為就是該考慮寫作這些文檔的必要性的時候了。

我們在文檔的時候，一定要明白為什麼要寫這些（無論是為了現在還是為了將來）。

12、仔細審視神話！

在實際的軟體工程的實施過程中，我們往往會遇到很多的神話，“軟體神話具有一些特徵使得它具有欺騙性……軟體神話仍被不少人相信著”（參見《軟體工程—實踐者的研究方法》P.10），如果，我們使用審視的眼光，而不是盲聽盲信的話，我們就有可能發現其中更多的玄妙了。

希望和大家共同努力，仔細審視軟體工程中存在的神話！