【轉】首先為人編寫程式，其次才是電腦

標籤：style   http   color   使用   os   io   strong   檔案   

        摘要：因工作忙，不少人只注重實現程式準系統，而忽略編程規範，結果是寫的代碼很難讀懂，甚至連閱讀自己的代碼都十分困難，這造成時間浪費，做事效率降低。而高手寫出的代碼都易領會，我們如何做也能像他們這樣呢？

    “首先是為人編寫程式，其次才是電腦”，這是軟體開發的基本要點，軟體的生命週期貫穿於產品的開發、測試、生產、發布、使用者使用、版本升級和後期維護等長期過程中，只有易讀、易維護的軟體代碼才具有生命力。

      在實際的軟體開發過程中，可能是由於工作很忙的原因，很多開發人員只注重實現程式的準系統，而忘記了編程規範，因此寫出來的代碼只能讓電腦看懂，人要看懂很不容易。更有甚者，有些項目組為了趕進度，明確要求組員以實現產品功能為主，代碼能夠運行起來就可以了。低要求產生低品質的代碼，既然“上頭”都這樣要求了，那還有必要寫出“讓人能夠讀懂”的代碼嗎？

如果不為人編程，帶來的後果是？

    進度是趕上了，產品也交付出去了，一切看來是OK的，但問題也就來了。前方產品故障頻發，後方開發人員不停地撲火。這個時候，他們才發現之前別人寫的代碼很難讀懂，甚至連閱讀自己寫的代碼都十分的困難，真是悔不當初。如果開始的時候能夠將代碼寫規範一點，文檔配備齊全一點，何至於此？

    “好”的代碼和“不好”的代碼給人的感覺是千差萬別。當我們看到優美的代碼時，會有一種想繼續研究下去的慾望，甚至會有一種覺得很享受的感覺。相反，當我們看到醜陋的代碼時，就會咬牙切齒，因為它不僅不利於閱讀，還會浪費我們很多時間，降低我們做事的效率。

一般說來，“好”的代碼和“不好”的代碼給我們的印象有如下幾種：

排版工整 VS 排版不工整

    我們開啟一個代碼檔案的時候，最先看到的就是其排版怎樣，這也是最直觀的感覺。當代碼排版工整時，我們很容易找出其條理和邏輯，會很快理解其到底要實現什麼功能；而排版不工整的時候，我們的眼睛會覺得很累，進而影響了我們的思維。

命名規範 VS 命名不規範

    在看完排版之後，我們就會看到每個函數和變數的命名。由於一般項目的程式碼數都比較多，我們不可能花很多時間去理解每個函數和變數到底是何用意，到底是拿來做什麼的。這就要求我們在編碼的時候，使函數和變數的命名具有自說明性，讓它們自己告訴讀者是做什麼用的，而不是要別人花大量時間去研讀後才能知道。這在一定程度上反映了開發人員的態度和專業化程度。

    例如，一個處理訊息的函數，命名為ProcessMsg和FunctionA，哪個更好呢？顯然是前者。我們只要一看到其名字，就知道它是做什麼用的。

    再如，有三個變數，命名為ReturnValue、MaxNum、SumOfTwoNum，我們就能一下子明白它們有何用途。第一個變數用於作為傳回值，第二個變數用來存放最大數，第三個變數用來存放兩個數之和。這太明顯了，你都可以不用去問元芳，自己就能搞清楚。而如果同樣三個變數，命名為i、j、k，你就無法一眼看出它們到底有什麼用，還要花大量的時間去閱讀代碼，甚至用幾個小時的時間，你還不知道它們有何用途。這時，你的老大來問你事情做得怎樣，你照實一說，他便說你無能。其實你是“啞巴吃黃連”，怪就怪別人沒有把代碼寫好。

注釋得當 VS 注釋不得當

   閱讀代碼，我們還會注意到其是否有注釋，注釋多還是少。這也是很直觀的。

    如果代碼實現的功能較為複雜，那麼添加註釋是必不可少的。在恰當的地方，使用恰當的注釋，能夠讓讀者覺得思路豁然開朗，他們會默默地在心裡感激你。注釋過少或沒有注釋是不行的，就像我們吃飯一樣。如果一碗青菜裡面什麼也沒有，你會覺得很乏味，沒有食慾。如果放上一點辣椒醬，就會覺得食慾倍增。不管你信不信，反正我是信了。

   但是，注釋也不能過多，不能將有用的代碼掩蓋住了，不能夠喧賓奪主，讓真正實現功能的代碼成了陪襯。

為人編程：如何才能寫出讓“人”看得懂的好代碼

    那麼，我們如何寫出讓“人”能夠看懂的“好”代碼呢？這個過程不能一蹴而就，要循序漸進，要從我做起，從身邊做起，不斷地提升個人編程的境界。

個人認為可以考慮從以下幾個方面入手：

    第一，對新入職的員工進行軟體編程規範的培訓。在剛開始工作中的時候，讓他們嚴格參照編程規範來編寫代碼。越早開展編程規範的訓練，越是能夠早地養成編寫規範代碼的習慣，寫出的代碼也就越清晰。順便說句題外話，很多IT公司沒有這方面的意識，只顧對企業文化進行培訓，以為這樣就能夠讓員工的忠誠度增加。實際上，這隻是個異想天開的做法。

    第二，定期在項目組開展編程規範方面的主題討論，強化大家的意識。老員工寫出的代碼對新員工有示範的作用，如果老員工寫出的程式都是可讀性很差的，那麼新員工會怎麼想呢？他們又會怎麼做呢？很多開發人員每天只顧埋頭苦幹，卻忽略了一些最基本的東西，因此能力很難再次得到提升。在編寫完代碼之後，不要就以為事情做完了，還要編寫一些項目文檔，如詳細設計文檔、單元/整合測試文檔等。在這些文檔裡面，把自己的思路寫清楚，方便以後自己或他人查閱起來能夠很快理解程式思路。

    第三，開發人員嚴格按照公司制定的編程規範來書寫代碼。變數如何命名？函數如何命名？注釋如何寫？代碼如何排版？這些都有嚴格的要求，作為一個合格的軟體開發工程師，編寫規範的代碼是基本的要求。當我們閱讀到書寫優美的代碼的時候，是不是心裏面會覺得很爽？從某種程度上來說，代碼編寫的規範程度可以體現一個程式員的態度和專業素養。

    第四，項目組要嚴格執行同行評審流程。大部分IT公司為了提高產品的品質，都有一個叫做“同行評審”的流程，也就是讓項目群組成員相互檢查各自的成果，大家相互學習、取長補短、共同提高。但是，可能是中國文化的影響，大家都比較顧及面子，因此不願意將對他人真實的想法表達出來，也使得“同行評審”流於形式。當然，也許你對別人的程式確實沒有意見，那就另當別論了。對他人開誠布公地提意見並不是冒犯，而是大家相互學習的一種很好的方式。

    第五，最重要的是，個人要有編寫規範代碼的意識，要不斷地學習各種提高編程能力的技術。不管別人對你怎麼說，如果你本人不想把程式寫好，那麼縱使萬般外力，又如何？程式員雖然工作很忙，但也要抽時間來學習新的技術，這樣才不會被新技術淘汰掉。

   “長風破浪會有時，直掛雲帆濟滄海”，對於很多人來說，編寫出能夠讓電腦讀懂的程式就已經足夠了，但如果想要成為一位優秀的軟體開發工程師，那麼就要力求寫出讓“人”能夠很容易看懂並領會的代碼。這是一個長期的過程，大家要有“萬裡長征”的準備，要有“愚公移山”的精神。