程式員-不要做敲代碼的機器

    第一次機房收費系統順利做完了，沒有嚴格的驗收就草草的了尾了，文檔馬馬虎虎照著模板改了改，UML在寫代碼過程中也被丟的九霄雲外了。 最終的結果就是：系統做完了，功能實現了，文檔，圖都扔一邊了，導致第二次驗收不合格，開始補文檔，補註釋，改圖。

    通過這次補文檔的收穫拿出來跟大家分享一下：

 

  1. 沒有文檔，就等同於敲代碼的機器，想到哪敲到哪，錯了重頭再來。

    在說文檔之前先看一下百科的解釋：軟體開發文檔是軟體開發使用和維護中的必備資料。它能提高軟體開發的效率,保證軟體的品質,而且在軟體的使用過程中有指導,協助,解惑的作用,尤其在維護工作中,文檔是不可或缺的資料。

    文檔在初學者看來（自己）有時候把它當做浪費時間的事情，個人開發可能體現不出來。一個Team開發至今看來我們還可以完成，是因為我們把本該存在的文檔化作了語言交流， 想想我們的合作開發是這樣嗎？就像軟體的介面不統一，再強大的功能也不能組裝到一起。

  2. 文檔是代碼的靈魂，讓代碼活起來

    做每件事情都跟寫文檔一樣，做好提前的規劃，就像我們的Google日曆一樣，我們只需要去做就可以了。如果程式員是敲代碼的機器，那文檔就是他們的靈魂。敲代碼只是把我們的想法落實到文字，把我們的思想用代碼體現出來。

  3. UML圖--可以改，但不能扔。

    ＵＭＬ圖是前期設計的模型，包圖提現了系統的整體架構，使用案例圖體現出系統的功能模組，時序圖把每個功能細化。ＵＭＬ圖可以說是代碼的前期映射，當往往敲代碼過程中會發現ＵＭＬ圖中的不足和缺陷，自己所犯的錯誤就是發現錯誤沒有改ＵＭＬ圖而是直接扔到了，按照自己的意願來。如果是合作開發的話，圖沒有更新，最終導致代碼整合不到一起。

　４. 代碼注釋

     沒有不需要修改的代碼，二次修改，多次修改，不同人修改。光禿禿的代碼在不熟悉業務的的情況下就是一堆亂碼。代碼維護可以說是天方夜譚。就連自己再補註釋的時候，看著自己寫的代碼都要思考半天。看代碼先看注釋，沒有注釋，無形中會增加工作量！

  5. 命名規範

    做軟體不是只是為了開發軟體，更重要的是維護軟體，直觀明了的命名規範使得代碼更有生命力，提高可理解性。

  總結：栽了個跟頭，疼但有收穫。回去看看又是另外一番收穫。學習就是這樣。代碼是有生命的，文檔，注釋，命名是我們程式員的三大法寶。與其說程式員是敲代碼的機器，不如說程式員是代碼的操控人。