《C++代碼整潔之道：C++17 可持續軟件開發模式實踐》 —1 簡　　介

第1章

簡　　介

如何去做和做到同樣重要。

—Eduardo Namur

目前大部分軟件項目的開發形勢依然很嚴峻，甚至有些項目處于嚴重的危機之中。其原因是多種多樣的，有的項目是由項目管理的糟糕導致的，有的項目則是由于開發過程中需求的不斷變化，而開發方式不能適應導致的。

在某些項目中，導致這一結果的只是單純的技術原因，即代碼質量不高。但這并不意味著代碼的功能沒有實現，相反代碼的外部質量看似很高，能夠通過質量保證部門的黑盒測試、用戶測試以及驗收測試。代碼能夠完美地通過QA，并且在測試報告上找不到任何錯誤。軟件用戶對軟件也很滿意，甚至軟件能夠按時交付并且不超出預算（當然，這種情況極少）。一切看起來很美好，但事實真的如此嗎？

真相是這份能夠正常工作的代碼的內部質量實際上很低。通常代碼可讀性不高，維護和擴展困難。軟件的組成單元，如類、函數非常臃腫，有的甚至會達到上千行的代碼量。太復雜的依賴關系導致的結果就是，改變其中某一小部分內容所造成的影響將是難以預估的。軟件的架構不具有前瞻性，其結構可能是由開發人員的臨時“拍腦袋”決定的，也就是一些開發人員常說的“歷史衍生軟件”或者“隨意的架構”。類、函數、變量、常量命名不規范，含義不明確，并且代碼被大量無用的注釋包圍，有些注釋已經過時了，有些注釋只描述了顯而易見的東西，甚至是完全錯誤的。不少開發人員害怕修改或擴展軟件，因為他們知道自己的軟件很脆弱，單元測試覆蓋率很低甚至沒有單元測試。在這樣的項目中，“不要碰已經能夠運行的系統”的聲音不絕于耳。一個新的特性從開發到部署上線，通常不是幾天就能完成的，這需要幾周甚至幾個月的時間才能完成。

這種糟糕的軟件通常被稱作“a Big Ball Of Mud”。這個術語由Brian Foote和Joseph W. Yoder在第四次模式編程語言會議上的一篇論文中第一次提到。Foote和Yoder將其解釋為“……結構隨意的、笨拙的、草率的、盤根錯節的代碼雜糅在一起”。這種軟件系統維護起來是一個噩夢，不僅代價高昂還會花費大量時間，它通常會拖垮整個開發團隊。

上述現象在整個編程領域中都客觀存在著，與使用哪種編程語言沒有關系，不管使用的是 Java、PHP、C、C#、C++，還是其他任何語言，都有可能產生“a Big Ball Of Mud”。那么，產生這一問題的根源是什么呢？

1.1　軟件熵

首先，有些東西就好像是一種自然規律，就像其他一些封閉和復雜的系統，軟件會隨著時間的推移而變得混亂，這種現象稱為軟件熵。這個詞借鑒了熱力學第二定律，意思是指，一個封閉系統的總混亂度不會減小，只能保持不變或增加。軟件的表現看起來就是這樣的，每次添加一個新功能或者改變一些原有功能，代碼都會變得更加混亂，有很多影響因素能夠提高軟件熵，舉例如下：

不切實際的項目進度安排會給程序員增加壓力，進而迫使開發人員以一種糟糕和非專業的方式處理開發工作。

當今，軟件系統大都龐大而復雜。

開發人員擁有不同的技能水平和開發經驗。

全球分布的、跨文化差異的團隊，執行和交流方面存在的問題。

開發人員主要關注軟件的功能性方面（功能性的需求和系統的用例），以致質量要求（例如非功能性要求），如性能、可維護性、可用性、可移植性、安全性等被忽略甚至被完全忘記了。

不當的開發環境和糟糕的開發工具。

管理層專注于眼前利益，而不了解可持續軟件開發的價值所在。

快速而糟糕的程序開發以及軟件設計與實現的不一致（例如破窗理論）。

破窗理論

破窗理論是在美式犯罪研究中發展起來的。該理論指出，一幢被遺棄的建筑物中的一個被破壞的窗戶，可能是整個周邊地區開始破敗的一個觸發器。破碎的窗戶給環境發出了致命的信號：“看，沒人在乎這幢大樓！”，這引起了進一步的腐化、破壞和其他反社會行為。破窗理論一直是刑事政策學的很多改革的基礎，特別是發展出零容忍策略。

在軟件開發中，該理論被采用并應用于代碼質量。對程序不適當的開發和糟糕的實現稱為“破窗”。如果這些不好的實現沒有被修復，那么會有更多不適當的代碼出現在它們周圍，因此，代碼的混亂就開始了。

不要容忍“破窗”出現在你的代碼中—及時地改正它們。

然而，似乎C和C++項目特別容易出現混亂，而且比其他編程語言更容易陷入一種糟糕的狀態。即使是在互聯網上，同樣也充斥著大量的、糟糕的C++代碼的例子，它們看起來快速且高度優化，但實際上是使用了高技巧的語法，并且完全忽略了設計良好和易維護的代碼的基本準則。

導致本節問題的原因之一可能在于C++是一個中等層次的多范型編程語言，即它包含了高級和低級語言的特點。使用C++編程語言，你可以編寫龐大且復雜的用戶界面的分布式業務軟件系統，也可以編寫小型的嵌入式實時響應系統，這要求與底層硬件密切關聯。多范型編程語言意味著你能夠編寫程式化、功能化或面向對象的程序，甚至三種范型的混合體。此外，C++支持模板元編程（Template Metaprogramming，TMP），這種技術用到了一種被稱作模板的東西，模板被編譯器用于生成臨時使用的源代碼，而這些臨時的源代碼會和其余的源代碼合并在一起，并進行編譯。自從ISO發布了支持C++11標準以來，更多的方法被加入到C++中，例如，具有匿名函數的函數式編程現在能通過lambda表達式以一種非常優雅的方式完成。由于這些多樣性能力，C++同時也具有非常晦澀難懂、復雜和煩瑣的名聲。

開發出糟糕軟件的另一個原因可能是很多程序開發者并沒有IT背景。如今，任何人都可以開始開發軟件，不必管他是否獲得了大學學位或者是否是任何其他計算機科學方面的人才。絕大多數C++開發者都是（或曾是）非專業人員，特別是在汽車、鐵路運輸、航空航天、電氣/電子或機械工程等技術領域。許多開發工程師在投入編程之前的幾十年里并沒有受到過計算機科學方面的教育，隨著復雜度的增加以及技術系統包含了越來越多的軟件，世界對程序員的需求很迫切，這種需求被現存的其他勞動力所補充了，電氣工程師、數學家、物理學家，還有很多人嚴格來講并非是經專業訓練過而開始開發軟件的，他們主要通過自學和實操而簡單地進行開發，并且他們已經盡了最大的努力。

基本上來看，這絕對是無可厚非的，但有時只知道開發工具和編程語言是不夠的！軟件開發與編程不一樣，世界上很多的軟件是由沒有經過培訓的軟件開發人員在一起開發和維護的，開發人員要在抽象層次考慮很多的事情，以便創建一個可持續的系統，例如架構和設計。如何構建高質量達到某些目標的系統？面向對象的東西有什么好處？我如何有效地使用它呢？某個框架或庫的優點和缺點是什么？各種算法之間的差異是什么？為什么同一個算法不適合所有類似的問題？到底什么是有限狀態機，為什么它有助于處理復雜性問題？

不要灰心！一個軟件的持續健康需要有人去關注它，而整潔的代碼就是處理的關鍵所在！

C++ c++

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。