程序員如何寫出優雅的代碼？
作者 | 老峰
責編 | 郭芮
一直以來，關於「代碼規範」的話題都備受關注，業界甚至有很多流傳甚廣的段子不斷調侃之。既然代碼規範能引起這麼大的共鳴，那麼今天我們談談一個程序員的自我修養——如何寫出優雅的代碼？
Martin（Bob大叔）曾在《代碼整潔之道》一書中說：當你的代碼在做 Code Review 時，審查者要是憤怒地吼道：「What the fuck, is this shit?」、「Dude, What the fuck！」等言辭激烈的詞語，那說明你寫的代碼是 Bad Code，如果審查者只是漫不經心的吐出幾個：「What the fuck?」，那說明你寫的是 Good Code。
衡量代碼質量的唯一標準就是每分鐘罵出「WTF」的頻率。
代碼不規範會有哪些痛點？
影響團隊合作，降低效率。對於共同完成項目的團隊而言，如果沒有統一的代碼規範，最終整合代碼時可能會出現看不懂命名或者閱讀過程不斷詢問的情況，導致團隊效率低下，甚至造成成員之間的矛盾。例如 git push -f，把別人的勞動成果全部覆蓋掉，出現一次就會遭到全員圍攻，豬隊友啊......
提高維護成本。代碼不規範導致可讀性降低，後期的代碼維護會耗費更多人力甚至財力成本.一旦代碼越來越多，最後的維護就難以為繼，會給運維人員造成很大負擔。
引發各種 bug。如果輸入輸出參數、異常處理、日誌處理等沒有規範，很容易導致大量低級 bug，還很難找到 bug 的原因。
不利於代碼審查，甚至造成安全漏洞。代碼審查是糾正代碼錯誤，保證開發周期安全順利進行的重要一步。如果代碼不規範，就會加重代碼審查的工作量和難度，導致代碼審查工作沒有根據還浪費時間。某些情況下，代碼不規範還會造成安全漏洞，此前 Morpheus 智能合約爆出的重大安全漏洞，就是大小寫錯誤造成的。
不利於程序員自身的成長。有些人可能沒有意識到代碼規範的重要性，有些人意識到了但由於項目時間緊、流程繁瑣等原因而不去遵循。這跟當前開發流程與安全之間的關係很像。很多人為了速度而犧牲前期的必要流程，卻給後續的工作帶來了更多麻煩。其實，規範的代碼有助於理解開發語言、模式和架構，也有利於提升開發水平。
X，哪個蠢貨寫的代碼！一看注釋，author是自己......如果你發現你之前的代碼很low，說明你已經進步了。那麼如何寫出優雅的代碼？
如何寫出優雅的代碼？
1、採用規範
每種語言都有自己的推薦風格，如Swfit最近有Google Swift Style Guide，顯然OC與Swift有著不同的風格。當我們開始寫Swift，首先要注意的就是按照Swift的風格寫，而不是沿用OC的風格，組內應該形成一種公認統一風格以便於後期維護。
從規範目標細節的角度，代碼規範分為：
注釋、命名、縮進空格、語句格式、規模、可靠性、語言特殊項。
2、Code Review
一份優雅、乾淨、整潔的代碼通常自帶文檔和注釋屬性，讀代碼即是讀作者的思路。我們在Review的過程中會發現很多不夠優雅的代碼，命名不規範者or影響性能，甚至存在致命bug。那麼如何在團隊內推行Code Review呢？我分享下我們組內目前採用的形式。
我們團隊內部採用Gitlab工具，在開始一個新的迭代後，每個同事為自己負責的模塊建立一個獨立分支，各自在自己獨立的分支完成開發，功能開發完成後，在Gitlab提交Merge Request，如果與其他同事模塊有依賴，或者業務較為複雜，可分為小的功能點多次提交；負責Code Review同事Review的時候應該先讓提交者講一下大概設計的思路，在GitLab中指出存在優化的點，待提交者修改完畢後再將該分支合入主幹分支。
引入Code Review的機制在一定程度上可以提升團隊內代碼質量，也可以減少低級bug的出現，對組內交叉熟悉彼此業務也有好處。
3、Code Lint
可能儘管我們推行了統一的代碼規範，也進行了CodeReview，我們會發現只要團隊成員足夠多，每位成員都有不同的背景，純靠人肉難免依然有不規範的代碼存在，那麼這個時候就應該採用Code Lint了。每種語言應該都有自己的編譯器對應的插件，以iOS為例有SwiftLint 、ocLint，這裡我簡單介紹下我們團隊內部使用的SwiftLint。
SwiftLint可以看作是一個Xcode插件，基於Sourcekit & Clang AST的應用（Sourcekit & Clang AST這裡不做過多介紹），通過語法規範檢查，可以在編譯期將所有不符合Swift規範的代碼全部用warning標註出來，一些嚴重的違背規則的代碼甚至讓它無法通過編譯（萬里江山一片黃）。
SwiftLint安裝很方便，Homebrew brew install swiftlint即可安裝好，然後為Xcode添加Run Script Phase。
接下來編譯，就可以看到99+ warning（如下圖所示）。請不要驚慌，我們可以使用swiftlint autocorrect自動解決部分警告，也可以通過.swiftlint.yml配置符合團隊規範的規則，通過編譯器檢查規範比人肉檢查更加準確高效細緻，團隊內部也可以做到高度統一的 Code Style。
4、閱讀學習交流分享
總結絕大多數開發者的日常，對新功能開發的迫切遠遠大於重構一個舊的功能，導致很多代碼都沒有很好的版本迭代。慢慢的，破舊、破損的模塊讓人覺得似乎無人照管，於是別人也不再關心，最終自己也參與破壞活動，走上一條打補丁的不歸路。
其實從一開始，我們就應該抱著一種重視自己的代碼的態度來寫代碼，而不是想著先完成功能，以後再來重構優化，代碼如生活：稍後就等於永不。如何保持代碼整潔，離不開設計模式和代碼重構，多閱讀開源社區的代碼，比如最近微信開源的MMKV就可以讀來學習，像世界同行大佬學習交流如何優雅的寫代碼，也可以讀一些經典的書籍如《代碼整潔之道》、《重構改善既有代碼的設計》、《重構改善既有代碼的設計》等等。
TAG:CSDN |