【轉】首先爲人編寫程序，其次纔是計算機

        摘要：因工做忙，很多人只注重實現程序基本功能，而忽略編程規範，結果是寫的代碼很難讀懂，甚至連閱讀本身的代碼都十分困難，這形成時間浪費，作事效率下降。而高手寫出的代碼都易領會，咱們如何作也能像他們這樣呢？

    「首先是爲人編寫程序，其次纔是計算機」，這是軟件開發的基本要點，軟件的生命週期貫穿於產品的開發、測試、生產、發佈、用戶使用、版本升級和後期維護等長期過程當中，只有易讀、易維護的軟件代碼才具備生命力。

      在實際的軟件開發過程當中，多是因爲工做很忙的緣由，不少開發人員只注重實現程序的基本功能，而忘記了編程規範，所以寫出來的代碼只能讓計算機看懂，人要看懂很不容易。更有甚者，有些項目組爲了趕進度，明確要求組員以實現產品功能爲主，代碼可以運行起來就能夠了。低要求產生低質量的代碼，既然「上頭」都這樣要求了，那還有必要寫出「讓人可以讀懂」的代碼嗎？

若是不爲人編程，帶來的後果是？

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

    「好」的代碼和「很差」的代碼給人的感受是千差萬別。當咱們看到優美的代碼時，會有一種想繼續研究下去的慾望，甚至會有一種以爲很享受的感受。相反，當咱們看到醜陋的代碼時，就會咬牙切齒，由於它不只不利於閱讀，還會浪費咱們不少時間，下降咱們作事的效率。

通常說來，「好」的代碼和「很差」的代碼給咱們的印象有以下幾種：

排版工整 VS 排版不工整

    咱們打開一個代碼文件的時候，最早看到的就是其排版怎樣，這也是最直觀的感受。當代碼排版工整時，咱們很容易找出其條理和邏輯，會很快理解其到底要實現什麼功能；而排版不工整的時候，咱們的眼睛會以爲很累，進而影響了咱們的思惟。

命名規範 VS 命名不規範

    在看完排版以後，咱們就會看到每一個函數和變量的命名。因爲通常項目的代碼行數都比較多，咱們不可能花不少時間去理解每一個函數和變量究竟是何用意，究竟是拿來作什麼的。這就要求咱們在編碼的時候，使函數和變量的命名具備自說明性，讓它們本身告訴讀者是作什麼用的，而不是要別人花大量時間去研讀後才能知道。這在必定程度上反映了開發人員的態度和專業化程度。

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

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

註釋得當 VS 註釋不得當

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

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

   可是，註釋也不能過多，不能將有用的代碼掩蓋住了，不可以喧賓奪主，讓真正實現功能的代碼成了襯托。

爲人編程：如何才能寫出讓「人」看得懂的好代碼

    那麼，咱們如何寫出讓「人」可以看懂的「好」代碼呢？這個過程不能一蹴而就，要按部就班，要從我作起，從身邊作起，不斷地提高我的編程的境界。

我的認爲能夠考慮從如下幾個方面入手：

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

    第二，按期在項目組開展編程規範方面的主題討論，強化你們的意識。老員工寫出的代碼對新員工有示範的做用，若是老員工寫出的程序都是可讀性不好的，那麼新員工會怎麼想呢？他們又會怎麼作呢？不少開發人員天天只顧埋頭苦幹，卻忽略了一些最基本的東西，所以能力很難再次獲得提高。在編寫完代碼以後，不要就覺得事情作完了，還要編寫一些項目文檔，如詳細設計文檔、單元/集成測試文檔等。在這些文檔裏面，把本身的思路寫清楚，方便之後本身或他人查閱起來可以很快理解程序思路。

    第三，開發人員嚴格按照公司制定的編程規範來書寫代碼。變量如何命名？函數如何命名？註釋如何寫？代碼如何排版？這些都有嚴格的要求，做爲一個合格的軟件開發工程師，編寫規範的代碼是基本的要求。當咱們閱讀到書寫優美的代碼的時候，是否是內心面會以爲很爽？從某種程度上來講，代碼編寫的規範程度能夠體現一個程序員的態度和專業素養。

    第四，項目組要嚴格執行同行評審流程。大部分IT公司爲了提升產品的質量，都有一個叫作「同行評審」的流程，也就是讓項目組成員相互檢查各自的成果，你們相互學習、取長補短、共同提升。可是，多是中國文化的影響，你們都比較顧及面子，所以不肯意將對他人真實的想法表達出來，也使得「同行評審」流於形式。固然，也許你對別人的程序確實沒有意見，那就另當別論了。對他人開誠佈公地提意見並非冒犯，而是你們相互學習的一種很好的方式。

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

   「長風破浪會有時，直掛雲帆濟滄海」，對於不少人來講，編寫出可以讓計算機讀懂的程序就已經足夠了，但若是想要成爲一位優秀的軟件開發工程師，那麼就要力求寫出讓「人」可以很容易看懂並領會的代碼。這是一個長期的過程，你們要有「萬里長征」的準備，要有「愚公移山」的精神。