為什麼軟體工程教科書上的內容和現實的軟體項目開發管理之間存在著一定差異？

前些天，有位同學軟體工程課的作業上，對於讀完《構建之法》之後問了幾個問題，其中兩個問題我印象比較深刻：一個問題是關於單元測試的，是不是必須所有分支，覆蓋率達到100%；另一個問題是關於如何結對編程的。

在讀2.1.2 好的單元測試的標準時，在P27中讀到了上文，作者說代碼覆蓋率需要考慮到每個模塊是否覆蓋到了每個函數，是否覆蓋到了每個語句，是否覆蓋到了每個條件分支，是否覆蓋到了每個布爾表達式的TURE|FALSE。但是在實際的軟體工程中，在進行單元測試時，我們真的要保證有100%的代碼覆蓋率嗎？是否只要保證了單元測試覆蓋了所有的代碼路徑之後，像是語句覆蓋之類的就可以不用全部代碼覆蓋了呢？就像如果出現了《100％代碼覆蓋率的悲劇》中提到的情況那樣，某段代碼功能看起來很簡單，沒有條件，沒有循環，沒有轉換，沒有任何複雜的東西，只是一段簡單的老膠水代碼。那麼這時候我們也需要對它們進行代碼覆蓋，進行測試嗎？這類的代碼我們是否也要對它們保證完全覆蓋呢？

在讀4.5.2 為什麼要結對編程時，在P85頁讀到了上文的內容，作者說兩人結對編程時，程序的質量將取決於水平較高的一位，也就是說在編程過程中是由水平較高的程序員作為主導。但是這樣的話，在進行編程的過程中，是否會出現水平較高的程序員長時間的掌控著鍵盤，而水平較低的程序員是否也會覺得由水平高的寫代碼能夠更好地完成項目或者課設，然後自己基本上沒有做什麼核心任務這種情況呢？那麼到項目結束時，就會出現不會的人還是不會，會的人更加會了的情況。像這樣的情況在我們的課設中也是可以看到的。如果我們想要避免出現這樣的情況，那麼在編程初期我們應該怎麼樣分配工作才能夠保證即有質有量地完成編程任務，不會出現代碼來不及寫的情況，又能夠讓兩個人都能夠都參與到主要代碼的編程中？怎麼樣的工作量才能夠讓結對編程的兩個人都能夠有所收穫呢？

我上學時也有過類似的困惑。當年因為自學了一些編程技術，所以有機會在學校的網路中心兼職，負責維護、改版學校的網站。日常的網站開發，也沒有用啥軟體項目管理知識，純粹就是小作坊式開發，畢竟網站也不算複雜，也還運行的不錯。

大三的時候我和另一個兼職的同學都轉到軟體學院去了，第一學期學的就是軟體工程，一學期課程上完，覺得軟體工程講的太好了，以前的做法簡直是土到家了，一點不科學。恰逢網站要改版，和同學一商量，都覺得項目開發，要文檔先行，一定要按照軟體項目管理的流程，先把需求分析文檔、設計文檔寫好，再著手開發！

關於文檔的重要性那是記得滾瓜爛熟，畢竟考試前剛背過，但是對於如何寫需求分析文檔和設計文檔，卻是兩眼一抹黑，那時候網上資源也不算太豐富，源代碼到處都是，偏偏文檔找不到可以借鑒參考的，於是整天都在琢磨如何寫文檔。結果到我們畢業的時候，文檔也沒憋出來，那次網站改版也宣告流產了！

這讓我對軟體工程產生了懷疑，為什麼我按照軟體工程講的反而做不出項目來了？

隨著時間推移，項目經驗的豐富，已經把這事都快忘記了，這兩個問題倒是讓我又有機會去反思一下：為什麼實際的項目和書本的介紹總是會有些出入？完全按照書本去做有時候反而畫虎不成反類犬？

如果只看單元測試問題：

• 單元測試，重要嗎？
  當然重要！
• 單元測試覆蓋率100%好不好？
  當然好！
• 既然如此我們以後項目必須要單元測試，所有代碼分支的覆蓋率必須100%
  這樣的規定就有問題了，因為它只是孤立的考慮了單元測試的重要性，而忽略了它對時間和成本的影響，也忽視了不同項目對單元測試要求的差異性。

單元測試的目的是什麼？保障代碼質量。換個角度說，就是單元測試是保障代碼質量的手段之一。再回想下軟體項目管理裡面的鐵三角，四個要素：時間、範圍、成本和質量之間是相互影響和制約的。

你的單元測試寫得好，可以提高代碼質量，但是需要更多的時間和成本，到底要把單元測試寫到什麼程度，完全取決於要如何平衡這幾個要素之間的關係。

一味的追求單元測試的覆蓋率，就陷入了教條主義的陷阱，錯把手段當目的！

再看結對編程和文檔的例子，也是類似的問題，結對編程和寫文檔，都是提高項目質量可以應用的手段，但並不是最終的目的。

在教科書上，各個章節都是相對獨立的，都是一個個的知識點，而現實的軟體項目是立體的，是需要將各個知識點組合在一起的。在學習這些知識點時，如果不能站在更高的角度去綜合看待，而是孤立的只看這一個知識點，就容易陷入教條主義之中，錯把手段當目的。

要對這類問題不困惑，總還是離不開做中學（Learning by Doing），在實際的項目積累經驗，對課本上理論知識進行印證。這樣遇到各種不同的項目場景的時候，能抓住重點和本質，採用適合的手段來達到項目的目標。Make it run, make it right, make it fast！

推薦閱讀：