為什么要規范編碼
前言：
為什么要規范編碼，我相信這是每個程序員都曾經思考過的問題，每個人都應該有每個人的答案，在這兒我只是想談一下我個人的感受，希望對剛入行的朋友能有所幫助。至於大神神馬的，可以略過~~~~~
場景：
要討論這個問題，我們首先得說點其他的。我們來假設一個場景：相信每個朋友最開始都有這種感受：哇，今天狀態超好，簡直是文若鉛華，絲若泉涌。敲起鍵盤來簡直感覺不要太順暢。隨着一連串的編寫，可能寫完抬頭一看一上午或者一下午就過去了。要么是飯點，要么就該要下班了。在想一想自己今天的狀態，那感覺不要太好。然后高高興興就回家或者吃飯去了。之前的事情告一段落。。。。。。。然后時間慢慢過去.....
問題來了：
3個月后，項目經理在團隊里面問道，之前的這個項目是誰負責的來着，然后順利的找到你，現在客戶有一些新的需求，既然之前是你寫的，那么你來改一下吧。。。
想着也確實是自己寫的，也沒有多大問題，稍微看下改了就是，於是乎痛苦的事情來了。下載了自己當初寫的源碼，打開一看，API注釋沒有寫全，代碼注釋基本沒有，當時的變量取名也比較隨心，是什么意思來着。。。。。。當初怎么想的，在大量的工作堆積下早已想不起來。花了半天時間看代碼，越看臉越黑，我相信此時這個代碼要是不是自己寫的，恐怕就已經要罵人了。
怎么解決：
那么此時的你改怎么辦呢，如果這是一個小項目，只有幾千行源碼，也許你會覺得重寫一遍遠比去理解當初的意思來的更快，然而，如果這是一個大項目呢，涉及的代碼量可能有幾萬行的時候怎么辦？毫無辦法，只能一步一步去嘗試理解，然后重新添加注釋，你會發現這需要花的時間成本太高了 ，長時間的加班就顯得不可避免，還會給領導落下個工作效率低下的映像。這都不是你所想要看到的結果。
實際案例：
在前不久，我們團隊接到一個項目，粗略的看了一下，源碼大概在1.3W+的樣子，
簡單的通過公司的質量檢測工具做了份質量評估報告：
API注釋率35%；
代碼注釋覆蓋率10%；
不符合編碼規范問題1W+；
存在嚴重阻斷100+；
拿到這個質量檢測報告我的內心是崩潰的，這等於這項目的源碼基本是看不了的。嘗試去閱讀理解然后對其進行維護的可能性基本等於零。
這使得我們不得不思考重寫整個項目的可能性，在用了大半個月的時間做可行性分析（包括原維護部門的人員交流，原開發部門的文檔補全，測試部門的測試用例。。等等）之后，我們得到了可以重寫的結論。接下來就是對新環境的搭建，新測試用例的搬遷，新單元源碼的重寫。。。。為此又付出的4個月左右的時間。前前后后加起來就是小半年。而這些時間本身是有必要付出的嗎？答案當然是否定的。
規范編碼的重要性：
通過以上的假設與實際例子我們不難看出，規范的編碼書寫習慣是一個程序員自我修養的必要素質。也許在我們一開始的時候會覺得這些條條框框是那么的煩人，以及沒有作用。但這是經過時間推敲的，是前人為我們總結下來的寶貴經驗，而且一旦你養成了良好的書寫習慣你會發現，看着有規范的代碼是一件多么讓人賞心悅目的事情~！（PS：如果你書寫的代碼都是高質量的代碼，那么你離漲工資就不遠了哦~~~~）
結尾語：
這篇文章主要是想跟剛入行的朋友們分享一下，在這個你原本可以以肆意書寫的世界，為什么要制定那么多的條條框框來束縛你的編碼。也是希望能警醒自己在編碼的過程中能始終如一的追求編碼的質量。而不是僅靠數量的堆疊。
歡迎更有感觸的朋友留下自己的心得分享吧~