為什么寫代碼要規范？可以說代碼是程序員的第二張臉

場景：

要討論這個問題，我們首先得說點其他的。我們來假設一個場景：相信每個朋友最開始都有這種感受：哇，今天狀態超好，簡直是文若鉛華，絲若泉涌。敲起鍵盤來簡直感覺不要太順暢。隨著一連串的編寫，可能寫完抬頭一看一上午或者一下午就過去了。要么是飯點，要么就該要下班了。在想一想自己今天的狀態，那感覺不要太好。然后高高興興就回家或者吃飯去了。之前的事情告一段落。。。。。。。然后時間慢慢過去.....

問題來了：

3個月后，項目經理在團隊里面問道，之前的這個項目是誰負責的來著，然后順利的找到你，現在客戶有一些新的需求，既然之前是你寫的，那么你來改一下吧。。。

想著也確實是自己寫的，也沒有多大問題，稍微看下改了就是，于是乎痛苦的事情來了。下載了自己當初寫的源碼，打開一看，API注釋沒有寫全，代碼注釋基本沒有，當時的變量取名也比較隨心，是什么意思來著。。。。。。當初怎么想的，在大量的工作堆積下早已想不起來?；税胩鞎r間看代碼，越看臉越黑，我相信此時這個代碼要是不是自己寫的，恐怕就已經要罵人了。

怎么解決：

那么此時的你改怎么辦呢，如果這是一個小項目，只有幾千行源碼，也許你會覺得重寫一遍遠比去理解當初的意思來的更快，然而，如果這是一個大項目呢，涉及的代碼量可能有幾萬行的時候怎么辦？毫無辦法，只能一步一步去嘗試理解，然后重新添加注釋，你會發現這需要花的時間成本太高了 ，長時間的加班就顯得不可避免，還會給領導落下個工作效率低下的映像。這都不是你所想要看到的結果。

實際案例：

在前不久，我們團隊接到一個項目，粗略的看了一下，源碼大概在1.3W+的樣子，

簡單的通過公司的質量檢測工具做了份質量評估報告：

　　API注釋率35%；

　　代碼注釋覆蓋率10%；

　　不符合編碼規范問題1W+；

　　存在嚴重阻斷100+；

拿到這個質量檢測報告我的內心是崩潰的，這等于這項目的源碼基本是看不了的。嘗試去閱讀理解然后對其進行維護的可能性基本等于零。

這使得我們不得不思考重寫整個項目的可能性，在用了大半個月的時間做可行性分析（包括原維護部門的人員交流，原開發部門的文檔補全，測試部門的測試用例。。等等）之后，我們得到了可以重寫的結論。接下來就是對新環境的搭建，新測試用例的搬遷，新單元源碼的重寫。。。。為此又付出的4個月左右的時間。前前后后加起來就是小半年。而這些時間本身是有必要付出的嗎？答案當然是否定的。

即使明白代碼規范的好處，但是有的迫于項目壓力，有的因為繁瑣的規范作出很多額外的工作，更有的不重視維護的問題，而很難貫徹代碼規范。

那么，我們需要了解，規范開發最大的受益人其實是自己！

你有沒有花費很多的時候查找自己的代碼呢？尤其是出現bug的時候需要逐行的debug？自己寫的代碼亂了頭緒的確實也見了不少。我們應該做的就是規范開發，減少自己出現的錯誤。很多時候項目的壓力一部分也是由于前期開發中遺留的眾多的問題。

還有的人覺得自己可以完成高難度的算法，就認為自己能力很強，不把規范放在眼里。很多人確實是這樣，追求個性，大概讓別人看他的代碼一頭霧水更覺得得意。殊不知復雜的算法確實可以體現你個人的邏輯能力，但是絕不代表你的開發水平。我們知道一些開源項目，一些大師級人物寫得程序都是極其規范的。并非規范了就代表高水平，實際上是規范的代碼更有利于幫助你理解開發語言理解模式理解架構，能夠幫助你快速提升開發水平。不明白這點，即使你寫的再高明的算法，沒準哪天也被當作亂碼別處理掉。

記住！每天壘亂碼（或許你不覺得，但是大多時候在別人眼中確實就是亂碼）并不能使你獲得更多的進步，相反要達到高水平的程序員，養成良好的開發習慣是絕對必需的。

不要沉迷表面的得失，看似無用的東西要經過慢慢的累積由量變達到質變的時候，你才能感受到其價值所在。

歡迎更有感觸的朋友留下自己的心得分享吧~

總結

以上是生活随笔為你收集整理的代码不规范？985,211也不要！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。