如何寫出優雅的程式碼
引言
中秋假期期間刷爆朋友圈的某篇10w+裡，標題赫然寫著“因程式碼不規範，碼農槍殺...”,其實上週五我就爬牆看了英文原文報道，報道中只是說在軟體公司發生槍擊案，警方只是宣佈作案動機不明，案情還待進一步調查。然後國內技術圈一些自媒體強行蹭熱點，紛紛以“程式碼不規範，碼農槍殺...”為題發文，甚至一些主流媒體如CSDN也不要職業操守跟風轉發，既然程式碼規範能引起這麼大的共鳴，那麼今天我們談談一個程式員的自我修養:如何寫出優雅的程式碼？
Martin(Bob大叔)曾在《程式碼整潔之道》一書中說：當你的程式碼在做 Code Review 時，審查者要是憤怒地吼道：
“What the fuck, is this shit?”
“Dude, What the fuck！”
等言辭激烈的詞語時，那說明你寫的程式碼是 Bad Code，如果審查者只是漫不經心的吐出幾個：
“What the fuck?”
那說明你寫的是 Good Code。衡量程式碼質量的唯一標準就是每分鐘罵出“WTF” 的頻率。
\
程式碼不規範會有哪些痛點？
1. 影響團隊合作，降低效率：對於共同完成專案的團隊而言，如果沒有統一的程式碼規範，最終整合程式碼時，可能會出現看不懂命名，或者閱讀過程不斷詢問的情況，導致團隊效率低下，甚至造成成員之間的矛盾；例如 git push -f，把別人的勞動成果全部覆蓋掉，出現一次就會遭到全員圍攻，豬隊友啊；
2. 提高維護成本：程式碼不規範導致可讀性降低，後期的程式碼維護會耗費更多人力甚至財力成本；一旦程式碼越來越多，最後的維護就難以為繼，給運維人員造成很大負擔；
3. 引發各種 bug：如果輸入輸出引數、異常處理、日誌處理等沒有規範，很容易導致大量低階 bug，還很難找到 bug 的原因；
4. 不利於程式碼審查，甚至造成安全漏洞：程式碼審查是糾正程式碼錯誤，保證開發週期安全順利進行的重要一步。如果程式碼不規範，就會加重程式碼審查的工作量和難度，導致程式碼審查工作沒有根據還浪費時間。某些情況下，程式碼不規範還會造成安全漏洞，此前 Morpheus 智慧合約爆出的重大安全漏洞，就是大小寫錯誤造成的；
5. 不利於程式設計師自身的成長：有些人可能沒有意識到程式碼規範的重要性，有些人意識到了但由於專案時間緊、流程繁瑣等原因而不去遵循。這跟當前開發流程與安全之間的關係很像。很多人為了速度而犧牲前期的必要流程，卻給後續的工作帶來了更多麻煩。其實，規範的程式碼有助於理解開發語言、模式和架構，也有利於提升開發水平。
艹，哪個傻逼寫的程式碼，一看註釋， 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就可以讀來學習，像世界同行大佬學習交流如何優雅的寫程式碼，也可以讀一些經典的書籍如《程式碼整潔之道》，《重構 改善既有程式碼的設計》， 《重構 改善既有程式碼的設計》這本書在之前的文章中提過，今天推薦一下《程式碼整潔之道》 。
《程式碼整潔之道》講述了一系列行對整潔程式碼之有效的最佳實踐。軟體質量，不但依賴於架構及設計，而且與程式碼質量緊密相關。這一點，無論是敏捷開發流派還是傳統開發流派，都有統一的認識。《程式碼整潔之道》提出一種觀念：程式碼質量與其整潔度成正比。乾淨的程式碼，既在質量上較為可靠，也為後期維護、升級奠定了良好基礎。作為程式設計領域的佼佼者，這些實踐在《程式碼整潔之道》中體現為一條條規則(或稱“啟示”)，並輔以專案例項的正、反兩面的範例。只要遵循這些規則，就能編寫出乾淨的程式碼，從而有效提升程式碼質量。
公眾號後臺回覆【程式設計之道】即可獲得電子版，建議讀者朋友購買紙質版閱讀，支援正版，支援原創。
更多騷操作，盡在iOSTips，關注公眾號，第一時間get新姿勢