爲何軟件工程教科書上的內容和現實的軟件項目之間存在着必定差別？

前些天，有位同窗軟件工程課的做業上，對於讀完《構建之法》以後問了幾個問題，其中兩個問題我印象比較深入：一個問題是關於單元測試的，是否是必須全部分支，覆蓋率達到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！