「首先是為人編寫程序，其次才是計算機」，這是軟體開發的基本要點，軟體的生命周期貫穿於產品的開發、測試、生產、發布、用戶使用、版本升級和後期維護等長期過程中，只有易讀、易維護的軟體代碼才具有生命力。
在實際的軟體開發過程中，可能是由於工作很忙的原因，很多開發人員只注重實現程序的基本功能，而忘記了編程規範，因此寫出來的代碼只能讓計算機看懂，人要看懂很不容易。更有甚者，有些項目組為了趕進度，明確要求組員以實現產品功能為主，代碼能夠運行起來就可以了。低要求產生低質量的代碼，既然「上頭」都這樣要求了，那還有必要寫出「讓人能夠讀懂」的代碼嗎？
進度是趕上了，產品也交付出去了，一切看來是OK的，但問題也就來了。前方產品故障頻發，後方開發人員不停地撲火。這個時候，他們才發現之前別人寫的代碼很難讀懂，甚至連閱讀自己寫的代碼都十分的困難，真是悔不當初。如果開始的時候能夠將代碼寫規範一點，文檔配備齊全一點，何至於此？
「好」的代碼和「不好」的代碼給人的感覺是千差萬別。當我們看到優美的代碼時，會有一種想繼續研究下去的欲望，甚至會有一種覺得很享受的感覺。相反，當我們看到醜陋的代碼時，就會咬牙切齒，因為它不僅不利於閱讀，還會浪費我們很多時間，降低我們做事的效率。
排版工整 VS 排版不工整
我們打開一個代碼文件的時候，最先看到的就是其排版怎樣，這也是最直觀的感覺。當代碼排版工整時，我們很容易找出其條理和邏輯，會很快理解其到底要實現什麼功能；而排版不工整的時候，我們的眼睛會覺得很累，進而影響了我們的思維。
命名規範 VS 命名不規範
在看完排版之後，我們就會看到每個函數和變量的命名。由於一般項目的代碼行數都比較多，我們不可能花很多時間去理解每個函數和變量到底是何用意，到底是拿來做什麼的。這就要求我們在編碼的時候，使函數和變量的命名具有自說明性，讓它們自己告訴讀者是做什麼用的，而不是要別人花大量時間去研讀後才能知道。這在一定程度上反映了開發人員的態度和專業化程度。
例如，一個處理消息的函數，命名為ProcessMsg和FunctionA，哪個更好呢？顯然是前者。我們只要一看到其名字，就知道它是做什麼用的。
再如，有三個變量，命名為ReturnValue、MaxNum、SumOfTwoNum，我們就能一下子明白它們有何用途。第一個變量用於作為返回值，第二個變量用來存放最大數，第三個變量用來存放兩個數之和。這太明顯了，你都可以不用去問元芳，自己就能搞清楚。而如果同樣三個變量，命名為i、j、k，你就無法一眼看出它們到底有什麼用，還要花大量的時間去閱讀代碼，甚至用幾個小時的時間，你還不知道它們有何用途。這時，你的老大來問你事情做得怎樣，你照實一說，他便說你無能。其實你是「啞巴吃黃連」，怪就怪別人沒有把代碼寫好。
注釋得當 VS 注釋不得當
閱讀代碼，我們還會注意到其是否有注釋，注釋多還是少。這也是很直觀的。
如果代碼實現的功能較為複雜，那麼添加注釋是必不可少的。在恰當的地方，使用恰當的注釋，能夠讓讀者覺得思路豁然開朗，他們會默默地在心裡感激你。注釋過少或沒有注釋是不行的，就像我們吃飯一樣。如果一碗青菜裡面什麼也沒有，你會覺得很乏味，沒有食慾。如果放上一點辣椒醬，就會覺得食慾倍增。不管你信不信，反正我是信了。
但是，注釋也不能過多，不能將有用的代碼掩蓋住了，不能夠喧賓奪主，讓真正實現功能的代碼成了陪襯。
那麼，我們如何寫出讓「人」能夠看懂的「好」代碼呢？這個過程不能一蹴而就，要循序漸進，要從我做起，從身邊做起，不斷地提升個人編程的境界。
個人認為可以考慮從以下幾個方面入手：
第一，對新入職的員工進行軟體編程規範的培訓。在剛開始工作中的時候，讓他們嚴格參照編程規範來編寫代碼。越早開展編程規範的訓練，越是能夠早地養成編寫規範代碼的習慣，寫出的代碼也就越清晰。順便說句題外話，很多IT公司沒有這方面的意識，只顧對企業文化進行培訓，以為這樣就能夠讓員工的忠誠度增加。實際上，這只是個異想天開的做法。
第二，定期在項目組開展編程規範方面的主題討論，強化大家的意識。老員工寫出的代碼對新員工有示範的作用，如果老員工寫出的程序都是可讀性很差的，那麼新員工會怎麼想呢？他們又會怎麼做呢？很多開發人員每天只顧埋頭苦幹，卻忽略了一些最基本的東西，因此能力很難再次得到提升。在編寫完代碼之後，不要就以為事情做完了，還要編寫一些項目文檔，如詳細設計文檔、單元/集成測試文檔等。在這些文檔裡面，把自己的思路寫清楚，方便以後自己或他人查閱起來能夠很快理解程序思路。
第三，開發人員嚴格按照公司制定的編程規範來書寫代碼。變量如何命名？函數如何命名？注釋如何寫？代碼如何排版？這些都有嚴格的要求，作為一個合格的軟體開發工程師，編寫規範的代碼是基本的要求。當我們閱讀到書寫優美的代碼的時候，是不是心裏面會覺得很爽？從某種程度上來說，代碼編寫的規範程度可以體現一個程式設計師的態度和專業素養。
第四，項目組要嚴格執行同行評審流程。大部分IT公司為了提高產品的質量，都有一個叫做「同行評審」的流程，也就是讓項目組成員相互檢查各自的成果，大家相互學習、取長補短、共同提高。但是，可能是中國文化的影響，大家都比較顧及面子，因此不願意將對他人真實的想法表達出來，也使得「同行評審」流於形式。當然，也許你對別人的程序確實沒有意見，那就另當別論了。對他人開誠布公地提意見並不是冒犯，而是大家相互學習的一種很好的方式。
第五，最重要的是，個人要有編寫規範代碼的意識，要不斷地學習各種提高編程能力的技術。不管別人對你怎麼說，如果你本人不想把程序寫好，那麼縱使萬般外力，又如何？程式設計師雖然工作很忙，但也要抽時間來學習新的技術，這樣才不會被新技術淘汰掉。
「長風破浪會有時，直掛雲帆濟滄海」，對於很多人來說，編寫出能夠讓計算機讀懂的程序就已經足夠了，但如果想要成為一位優秀的軟體開發工程師，那麼就要力求寫出讓「人」能夠很容易看懂並領會的代碼。這是一個長期的過程，大家要有「萬裡長徵」的準備，要有「愚公移山」的精神。
作者介紹：周兆熊，重慶潼南人。2009年7月畢業於海南大學通信工程專業，2012年4月畢業於南京郵電大學計算機應用技術專業，獲工學碩士學位。現在中興通訊股份有限公司重慶研發中心從事軟體開發工作。微博：@周兆熊，微信：245924426。
《暢言》第十三期：【[暢言]程式設計師的成功是否有規律可循？】自然界中存在許多規律，那麼在程序人生上是否有規律可循呢？這種規律是如大多數人期望的那樣嗎？V眾投發起人李智勇對此進行了探討，他分析了必然與偶然、本質與細節，並就程序人生規律的三要素進行了解讀。
《暢言》第十四期：【[暢言]公司應不應該禁止程式設計師上網？】應不應該禁止員工上網？這雖然是個其傻無比的問題，但仍然有公司去實踐，尤其是做傳統軟體、外包、電信的更容易選擇封殺堵截。這樣無非是兩個原因，一個是信息安全，一個是希望提高效率。然而其所來的危害很大。
《暢言》第十五期：【[暢言]程式設計師既要寫好代碼，又要寫好文檔】程式設計師是否應該注重文檔的編寫？這是一個看似很小但卻比較重要的問題。軟體除了程序和數據外，還包括文檔。其次，如果程式設計師只是會寫程序，不能在文檔中恰當且優雅地描述自己的想法，那麼就真的是「碼農」了。
《暢言》是CSDN新欄目，供大家各抒己見。只要你看完CSDN文章或評論後有話說，都可以通過電子郵件（zhangyong@csdn.net）投稿，從而獲得上CSDN首頁表達自己觀點、想法的機會。《暢言》不怕觀點「雷人」，只要你邏輯表達清楚、數據引用可靠，你敢投稿，我們就敢首頁！歡迎大家暢所欲言。
本文為CSDN原創文章，未經允許不得轉載，如需轉載請聯繫market#csdn.net(#換成@)