程式設計師如何寫出優雅的代碼?

2022-01-02 CSDN

作者 | 老峰

責編 | 郭芮

一直以來，關於「代碼規範」的話題都備受關注，業界甚至有很多流傳甚廣的段子不斷調侃之。既然代碼規範能引起這麼大的共鳴，那麼今天我們談談一個程式設計師的自我修養——如何寫出優雅的代碼？

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就可以讀來學習，像世界同行大佬學習交流如何優雅的寫代碼，也可以讀一些經典的書籍如《代碼整潔之道》、《重構改善既有代碼的設計》、《重構改善既有代碼的設計》等等。

聲明：本文為公眾號 iOSTips 投稿，版權歸對方所有。

推薦閱讀：

相關焦點

  • 如何寫出優雅的C++代碼
    工欲善其事必先利其器，
  • 一步一步,寫出優雅的程序(二)——駝峰命名法和代碼自測
    文/Edward我們在上一篇文章「一步一步，寫出優雅的程序
  • 如何寫出高質量可讀性強的代碼?長文詳解
    好的代碼也是讓人陶醉的，那麼如何寫出好的代碼？高質量代碼有三要素：可讀性、可維護性、可變更性。我們的代碼要一個都不能少地達到了這三要素的要求才能算高質量的代碼。一提到可讀性似乎有一些老生常談的味道，雖然大家一而再，再而三地強調可讀性，但我們的代碼在可讀性方面依然做得非常糟糕。由於工作的需要，常常需要去閱讀他人的代碼，維護他人設計的模塊。
  • 如何一本正經地寫出別人無法維護的代碼?
    作者 | 阿木責編 | 伍杏玲編寫除了自己沒人能看懂的代碼，是一種怎樣的體驗？下面由作為資深挖坑程式設計師的我，手把手教大家這是怎麼做到的？如果各位可以在接下來的時間多加練習，所謂青出於藍勝於藍，相信各位不但可以寫出別人無法維護的代碼，還可能在有朝一日，甚至能技藝爐火純青地寫出自己都維護不了的代碼。
  • 寫出漂亮 Python 代碼的 20條準則
    https://www.python.org/dev/peps/pep-0008/瀏覽完 PEP8 後，看看下面這些文章，其中展示了一些亮點和應用：如何參照 PEP 8 編寫漂亮的 Python 代碼https://realpython.com/python-pep8/優雅的 Python 與 PEP8https:/
  • 作為程式設計師的你,除了擼代碼,還能幹什麼?
    外界傳聞「程序猿」只會敲代碼，以至於人們常常將在 IT 公司工作的人認知為單一物種。作為一名程式設計師，除了敲代碼之外還應該有一些副業。什麼是副業？副業就是主要事業以外附帶經營的事業。這個對程式設計師的背景要求比較高，最好是有大廠經歷和大體量項目經驗，但其收入差異化嚴重，少的幾千，多的幾萬，需要有比較好的資源積累。2、出書。
  • 程式設計師去網吧寫代碼,被當黑客,網管報警
    想一想，在網吧有見過看新聞聯播的人；有寫作業的人；有看高數教學視頻的人，從來沒看過在網吧寫代碼的人。想一想別人在網吧，五個人一排五黑玩遊戲，他們在網吧一排五黑寫代碼，那個畫面是誰都會好奇地圍過來吧。在外人看來程式設計師是很神奇的，他們敲敲鍵盤就能改變許多東西，他們感覺程式設計師就是黑客。然後這五個人就真的被當成黑客了，網管報警了。
  • 程式設計師最愛用的10款JavaScript編輯器
    對於一名JavaScript程式設計師來說，目前有很多很好的代碼編輯器工具可以去選擇。
  • 文末送書|教你5招,輕鬆寫出優雅的Python代碼
    在Python中，一般稱優雅的代碼為Pythonic。以我的理解，所謂Pythonic就是用Python的方式寫出簡潔優美的代碼。今天我教大家5種寫出簡潔優美的代碼的方法，相信看完本篇文章後你會對如何編寫Python有不一樣的理解。
  • 數學公式太晦澀,不如用代碼寫出來:這是程式設計師學數學的獨特方式
    我發現代碼不僅能用來寫程序，而且還是用於解釋複雜問題的全球通用語言。當我學習數據科學背後的數學時，我總是發現理解數學的最佳方式是寫出描述這些等式的代碼段。最終，我理解了這些符號，現在讀它們就像讀一篇普通論文一樣。我希望通過這篇文章分享一些示例，讓大家知道用代碼描述數學竟會如此簡單！
  • 如此沙雕的代碼注釋,原來程式設計師都是段子手!
    我們這才知道，原來程式設計師個個都是段子手；這麼多年來，我們也走過了他們的無數套路...... 首先，產品經理，是永遠永遠吐槽不完的！網友的評論也非常扎心，說看這些代碼就像在閱讀程式設計師的日記，每一頁都寫滿了對產品經理的恨。
  • 新一代程式設計師都用什麼IDE寫代碼
    但是，如何為自己選擇 合適IDE 的文章並不多。需要注意的是，並非任何 IDE 都可以寫好程序。我們必須找到自己需要的功能以及想要有的功能的 IDE產品。對於任何語言的開發人員來說，擁有完善強大的 IDE 非常重要——IDE 能夠代表項目的創造力、專業性和工作水平。由於開發人員和程式語言眾多，會有許多不同的 IDE供人們選擇。通常，程式設計師可能會發現好的 IDE 是良好個人習慣的延伸。
  • VS Code能自己編程了,GitHub推出「AI程式設計師」插件,根據注釋自動補全代碼
    現在，GitHub官方和openAI聯合為程式設計師們送上編程神器——GitHub Copilot。AI來給你打工當秘書，從此寫代碼不用再去Stack Overflow上瘋狂搜索了，效率立刻翻倍！這個系統可以像有高手指點一樣，配合程式設計師寫代碼。
  • 程式設計師一天工作量改了5行代碼,工作很輕鬆?
    領導安排張工跟進，接到任務，張工第一時間就是想重現這個問題，可是怎麼也復現不了，費了九牛二虎之力，終於從上萬行代碼中定位到問題所在，最後張工修改了5行代碼，問題解決了。這時已經快下班了。張工伸了一下懶腰，這時財務漂亮妹子過來了，找張工確認交通費用報銷的事情，見張工懶羊羊的。
  • 做為一名程式設計師應該有的的好習慣
    做為一名程式設計師應該有的的好習慣 標籤： 程式語言版權 1、多思考，多動腦。 在編程或者思考算法建立框架時，不要急著寫代碼，應當先規劃好整體的框架，再動手，要嘗試提高代碼的整潔度和分離度，有利於為代碼編寫單元測試，提高代碼的質量。
  • @程式設計師:可以被認出是寫代碼的,但是不能因為格子襯衫!
    是這樣的：看來程式設計師在短期內撕掉「格子襯衫」的標籤是不太可能了，有人說格子襯衫是程式設計師的信仰……就像信仰「1024」、就像滿是BUG的代碼一樣，要有生命力不如咱把「bug「與代碼穿在身上，與格子襯衫劃清界限，但是我仍是端端正正的程式設計師~比如這樣：
  • 代碼你打算寫到幾歲?雷軍、張一鳴都曾寫過...
    這也代表，他們已經通過寫代碼創造出市場最需要的產品，實現巨大商業價值。而他們曾經寫出的代碼，即便放到今天，也會被很多開發者交口稱讚。當然，也有人在功成名就之後，把寫代碼當做新的生活，從頭學起——潘石屹在56歲生日當天，宣布開始學習 Python。現在就來盤點一下，中國的商業大佬們曾經用代碼寫的故事。
  • 寫膩了代碼、難再「996」 中年程式設計師拿什麼和年輕人拼?
    他們處於「老楊頭」年輕時的巔峰狀態——夜深人靜時寫代碼，可以沉迷其中忘記睡覺。 比思維，長期工作習慣形成路徑依賴，思維革新談何容易。抖音、王者榮耀、吃雞很火，但中年程式設計師有可能還是喜歡玩紅色警戒，看《康熙王朝》……何熙說：「中年程式設計師可能不喜歡新的東西，思維套在以前，如果仍然保持這樣的思維，程式設計師這條路就走不通。」
  • 程式設計師35歲之後就寫不動了?看看81歲圖靈獎得主是怎麼做的!
    在程式設計師領域有一個問題討論很廣，就是程式設計師在35歲之後有哪些出路。很多人看來程式設計師是個門檻高、薪資高、就業簡單的行業。程式設計師趕上了十年來網際網路的高速發展，拿的薪資是同齡人的幾倍，多數人羨慕這個行業，也認為只要程式設計師有技術，找工作不是難事但是敲代碼的程式設計師與大多數行業一樣也是吃青春飯的一個行業。人們只看到程式設計師月薪幾萬，但很少人知道他們為了趕一個項目一個月只有三天回家睡覺。很多人見過程式設計師們早上十一點才穿著拖鞋大褲衩去上班，可沒見過凌晨3點、4點、5點的城市。加班到夜裡是常有的事。
  • 為什麼程式設計師更喜歡夜間工作?
    有人說，程式設計師是一種神奇的動物：喝的是咖啡，擠出來的是代碼。