1. 熵的故事
熵的概念最早起源于物理學(xué)，用于度量一個熱力學(xué)系統(tǒng)的無序程度。熱力學(xué)第二定律，又稱“熵增定律”，表明了在自然過程中，一個孤立的系統(tǒng)總是從最初的集中、有序的排列狀態(tài)，趨向于分散、混亂和無序；當熵達到最大時，系統(tǒng)就會處于一種靜寂狀態(tài)。
通俗的講：系統(tǒng)的熵增過程，就是由原始到死亡的過程。“熵” 是 “活躍” 的反義詞，代表負能量。
物質(zhì)總是向著熵增演化：
自然界除了自然風(fēng)化的作用，也少不了人為的因素。
1982年3月，詹姆士·威爾遜（James Q. Wilson）及喬治·凱林（George L. Kelling）發(fā)表一篇題為《Broken Windows》的文檔，提出了犯罪學(xué)的一個理論 – 破窗效應(yīng)。此理論認為環(huán)境中的不良現(xiàn)象如果被放任存在，會誘使人們仿效，甚至變本加厲。
一個房子如果窗戶破了，沒人去修補，隔不久，其他的窗戶也可能莫名奇妙地被人打破。環(huán)境可以對一個人產(chǎn)生強烈的暗示性和誘導(dǎo)性。
這個理論從另一個側(cè)面說明了對一個系統(tǒng)需要及時維護，以減少人為的熵增現(xiàn)象。古人云：勿以惡小而為之，勿以善小而不為。
對于我們創(chuàng)造的代碼，也是一樣，大家制定了編碼規(guī)范，以期盡量減緩熵增，從而達到延長軟件的生命周期。
2. 代碼檢視的意義
代碼檢視一直被認為是提高代碼質(zhì)量的重要手段，同時也是發(fā)現(xiàn)潛在問題的重要途經(jīng)。代碼檢視有以下重要意義。
2.1. 編寫易于理解的代碼
代碼檢視是確保代碼質(zhì)量的重要環(huán)節(jié)，它有助于開發(fā)人員編寫易于理解的代碼。
微軟和谷歌等公司在代碼檢視中積累了豐富的經(jīng)驗，強調(diào)了代碼的可讀性對于團隊協(xié)作的重要性。當代碼清晰、結(jié)構(gòu)良好時，其他開發(fā)人員能夠更快地理解代碼的功能和目的，從而提高團隊的整體效率。此外，良好的代碼可讀性也有助于新成員快速融入團隊，因為他們可以更容易地理解現(xiàn)有的代碼庫。
史蒂夫·邁克康奈爾的《代碼大全》，被福布斯技術(shù)委員會（Forbes Council）譽為“有史以來最好的軟件開發(fā)基礎(chǔ)書” 。
《代碼大全》書中提到了提高代碼可讀性的多種方法，包括使用有意義的變量名、避免嵌套過深的語句、使用函數(shù)和模塊、面向?qū)ο缶幊獭⒈苊庵貜?fù)代碼、使用設(shè)計模式、編寫注釋和文檔、使用調(diào)試工具、進行代碼審查、學(xué)習(xí)和使用更高級的編程語言和技術(shù)等等。
軟件工程的核心就是管理復(fù)雜度。規(guī)模更大的項目，如果不對復(fù)雜性做出限制，那么項目的每個步驟都可能崩潰失控。以往，無數(shù)大型項目都在砸下巨量資金后失敗了，原因就是其過于復(fù)雜，已經(jīng)無人能理解究竟發(fā)生了什么，就如同過于龐大的巨獸被自身重量所壓垮。
復(fù)雜性其實貫穿于軟件開發(fā)的各個階段，復(fù)雜性在編碼過程中，如果底層代碼的質(zhì)量不好，超大規(guī)模系統(tǒng)也可能就由此崩潰。所以必須立足底層，立足細節(jié)抓代碼質(zhì)量，關(guān)注每個語句、例程和類，步步為營，以此為基礎(chǔ)才能擴大規(guī)模，同時繼續(xù)保持代碼質(zhì)量，即在設(shè)計和架構(gòu)層級控制復(fù)雜性，對復(fù)雜性控制要廣泛而深入地體現(xiàn)在軟件開發(fā)的各個階段。
唐納德·克努特（Donald Knuth），他在編程界被廣泛認為是“計算機程序設(shè)計藝術(shù)”的創(chuàng)始人之一。克努特曾說過：“ are meant to be read by humans and only for to execute.” 這句話強調(diào)了代碼的可讀性對于人類的重要性，意味著代碼首先應(yīng)該是為了讓人理解而編寫的，而機器執(zhí)行只是其次。
這是《A guide to object- metrics》中的一個統(tǒng)計圖，作者分析了一個數(shù)據(jù)庫系統(tǒng)，黃色柱狀體是缺陷的百分比，紅色柱狀體是代碼的比例，橫坐標標識了不同圈復(fù)雜度。最左邊代碼圈復(fù)雜度在0-5的時候，代碼量占了總量的40%，缺陷數(shù)占了10%，而最右邊圈復(fù)雜度為15+， 代碼量占比10%，但缺陷數(shù)量占了缺陷總數(shù)的40%+。從左向右的可以看到代碼的圈復(fù)雜度越高，缺陷的比例也越高。
通常我們不能一次性編寫出完全滿足需求的代碼；或者需求在不斷的變化；維護代碼的人往往不是原始開發(fā)的人員，這些都要求我們編寫的代碼是可被另一個人所理解和修改的。
2.1.1. 維護規(guī)范
代碼檢視是維護編碼規(guī)范的關(guān)鍵機制。
代碼的可讀性、可維護性需要具體的規(guī)約來保持。我們往往通過編碼規(guī)范來維護和保持代碼的易于理解和避免一些常見的錯誤（或被稱為最佳實踐）。因此各大公司都有了自己的編碼規(guī)范，比如我們熟知的google的編碼規(guī)范。同時行業(yè)也為了維護行業(yè)的統(tǒng)一性，也給出了行業(yè)的編碼規(guī)范，像MISRA C 2012、AUTOSAR C++14 等等。更多的關(guān)于規(guī)范的信息，可參考《一圖看懂軟件缺陷檢查涉及的內(nèi)容-云社區(qū)-華為云》。
通過代碼檢視，可以確保所有代碼都遵循了既定的編碼標準和最佳實踐。這有助于保持代碼庫的一致性，減少由于風(fēng)格不一致或不遵循規(guī)范導(dǎo)致的維護問題。
目前的編碼規(guī)范通常會包含兩部分：
一致的代碼風(fēng)格。整個項目中保持一致的編碼風(fēng)格，可以減少開發(fā)者在閱讀不同部分代碼時的認知負擔，因為他們不需要適應(yīng)不同的風(fēng)格。這包括：
編碼實踐
每個編程語言都有自己的特點和特定的規(guī)約，很多地方往往被開發(fā)人員忽略從而埋下潛在的風(fēng)險。
這部分通常包括：
規(guī)范的維護還有助于提高代碼的可維護性和可擴展性，因為所有開發(fā)人員都遵循相同的規(guī)則和模式。
目前規(guī)范的很多部分都能夠被靜態(tài)分析工具檢測到，甚至自動修復(fù)。這些工具的告警也會在代碼檢視的時候得到確認，是否是誤報，還是確實需要修改。對被確認誤報的部分會反饋給工具團隊，進一步的修正檢查工具，起到對工具反饋的作用。
此外，代碼檢視還可以作為規(guī)范更新和改進的反饋機制，團隊可以根據(jù)實際開發(fā)經(jīng)驗，不斷調(diào)整和完善編碼規(guī)范，以適應(yīng)不斷變化的開發(fā)需求和技術(shù)進步。
2.1.2. 學(xué)習(xí)和教育
代碼檢視為開發(fā)人員提供了學(xué)習(xí)和教育的機會。
在微軟和谷歌等公司，代碼檢視被視為一種學(xué)習(xí)和知識共享的平臺。通過檢視他人的代碼，開發(fā)人員可以學(xué)習(xí)到新的編程技巧、設(shè)計模式和最佳實踐。
同時，代碼的作者也可以從其他開發(fā)人員的反饋中學(xué)習(xí)，了解自己的代碼在哪些方面可以改進，這對于個人技能的提升非常有幫助。代碼檢視還可以作為一種教育工具，幫助新員工快速了解公司的代碼風(fēng)格和開發(fā)流程。通過參與代碼檢視，新員工可以更快地融入團隊，提高自己的開發(fā)能力。
代碼檢視還可以揭示潛在的設(shè)計問題，促進團隊成員之間的知識共享，增強團隊的凝聚力。通過代碼檢視，開發(fā)人員能夠從同事那里得到反饋，學(xué)習(xí)如何寫出更清晰、更高效的代碼，這對于個人技術(shù)成長和團隊協(xié)作都是有益的。
2.1.3. 把關(guān)和事故預(yù)防
代碼檢視在把關(guān)和事故預(yù)防方面起著至關(guān)重要的作用。
代碼檢視除了確保代碼的質(zhì)量，還可以防止?jié)撛诘腻e誤和缺陷進入生產(chǎn)環(huán)境。代碼檢視可以幫助開發(fā)人員發(fā)現(xiàn)代碼中的錯誤，包括邏輯錯誤、性能問題、安全漏洞等，從而在代碼發(fā)布前進行修復(fù)。這不僅可以減少生產(chǎn)環(huán)境中的問題，還可以降低維護成本和風(fēng)險。
雖然靜態(tài)分析工具在缺陷檢查上承擔了越來越重要的防護作用，可畢竟檢查能力在開發(fā)框架和第三方調(diào)用上，需要很多的人為配置才能使分析工具在很大程度上識別框架上潛在的調(diào)用關(guān)系和第三方函數(shù)的行為。目前靜態(tài)分析工具在這方面都還有很大的欠缺，這將導(dǎo)致很多的漏報。所以代碼檢視在防范代碼缺陷上還是不可缺少的檢查環(huán)節(jié)。
隨著外部的惡意攻擊的增加，缺陷的發(fā)現(xiàn)和漏報的矛盾也越發(fā)的突出。
檢查工具畢竟只是輔助，還是需要開發(fā)人員建立安全防范意識，寫出沒有缺陷的代碼，這個才是安全預(yù)防的治本方法。通過代碼檢視，團隊可以建立起一種預(yù)防文化，不斷提高代碼質(zhì)量，減少事故發(fā)生的概率。
3. 代碼檢視中需要注意的問題3.1. 代碼檢視的文化建設(shè)
將代碼評審用作團隊建設(shè)活動，培養(yǎng)對發(fā)現(xiàn)缺陷的積極態(tài)度。為所有團隊成員提供糾正壞習(xí)慣、學(xué)習(xí)新技巧和擴展能力的機會。
尊重和鼓勵、禮貌和專業(yè)精神；
3.2. 代碼檢視提交
一次代碼提交不易過大
對思科系統(tǒng)編程團隊的一項研究表明，開發(fā)人員一次審查的代碼行數(shù)不應(yīng)超過200到400行（LOC）。大腦一次只能有效地處理這么多信息;超過 400 LOC，發(fā)現(xiàn)缺陷的能力會減弱。
在實踐中，在 60 到 90 分鐘內(nèi)對 200-400 LOC 進行審查應(yīng)該會產(chǎn)生 70-90% 的缺陷發(fā)現(xiàn)。因此，如果代碼中存在 10 個缺陷，那么正確進行的審查會發(fā)現(xiàn)其中的 7 到 9 個。
研究表明，以每小時 500 LOC 的速度快速下降，缺陷密度顯著下降。在有限的時間內(nèi)以合理的速度進行合理數(shù)量的代碼審查，從而產(chǎn)生最有效的代碼審查。
在代碼提交檢視前還需要完成以下工作：
3.3. 代碼檢視審核的主要內(nèi)容
代碼審核人員在審核過程中主要的審核內(nèi)容包括：
4. 代碼檢視中需要注意的安全問題
結(jié)合業(yè)界的主要安全編碼問題，總結(jié)了代碼檢視的安全檢查清單如下。
注：下面問題涉及的 CWE 有的是類別，需要包括下面的子CWE編號。
4.1. 外部輸入校驗
[ ] 是否有外部輸入，例如：http request, 表單輸入、配置文件、數(shù)據(jù)庫讀？
防范的問題：
4.2. SQL 檢查
[ ] 是否有 SQL 操作？
防范的問題：
4.3. 命令執(zhí)行檢查
[ ] 是否有命令操作？
防范的問題：
4.4. 文件操作
[ ] 是否有文件操作？
防范的問題：
4.5. 不安全反射
[ ] 是否有反射操作？
防范的問題：
4.6. 輸出到頁面
[ ] 是否有頁面輸出操作？
防范的問題：
4.7. 輸出到日志
[ ] 是否有日志輸出操作？
防范的問題：
4.8. 數(shù)據(jù)傳輸
[ ] 是否有數(shù)據(jù)傳輸操作？
防范的問題：
4.9. 安全加密
[ ] 是否有加解密操作？
防范的問題：
4.10. 權(quán)限控制
[ ] 是否有權(quán)限驗證、設(shè)置、變更操作？
防范的問題：
5. 參考
關(guān)注#華為云開發(fā)者聯(lián)盟# 點擊下方，第一時間了解華為云新鮮技術(shù)~
華為云博客_大數(shù)據(jù)博客_AI博客_云計算博客_開發(fā)者中心-華為云