接手專案最痛恨的事情

1、純專案，沒文件..

       當你接手一個別人已經開發一半的專案的時候，你看到的是他們已經開發一半的專案，可是文件卻是層次不齊，需求文件、設計文件都沒有， 僅有幾個介面文件，當你看到這種的時候，心中有一萬頭草泥馬在蹦騰....  做專案，文件很重要，有了文件，能讓接手的人不用看程式就知道，這個專案是幹嘛的...

2、專案結構，無層次感

     拿到一個專案，文件都有了，可是看專案程式碼的時候，程式碼一團糟， 業務程式碼寫在了控制器、DAO層裡面。 控制層還做了很多亂七八糟的操作...專案結構一團糟，實體類、實現類的到處放...哎，只能說：這是哪個王八新人乾的事情   養良好的習慣，寫程式學會歸類，不通的程式碼放在不通的層次裡面，現在市面上流行的mvc開發模式不是沒有道理...這樣便於以後維護，也便於觀看...

3、程式碼無註釋，詛咒不寫註釋的人 JJ跟註釋一樣長

     接手新專案的時候，或者維護別人專案的時候，看到那成堆的程式碼，很多地方不理解，可是註釋一行都沒有，或者就那麼1-2行.. 只能詛咒：這個不寫註釋的人，JJ應該跟註釋一樣長.....  程式設計師養成寫註釋的習慣很重要，每個人的記憶能力都有限，如果長時間沒去看自己寫的程式碼，再回過頭來看的話，估計寫的那個人都不一定能看懂...

4、程式碼繁多，無用程式碼多，一個方法幾千行..

    作為一個程式設計師，編寫程式碼必須要有良好的習慣，能重構的就重構，能封裝的就封裝，不要覺得這個是簡單的事情，你要有遇見未來的想法，要讓程式有可擴充套件性、可維護性。

而且如果以後程式改動，可能你連程式碼都不需要改，只需增加配置檔案就行..而且封裝和重構之後，你的程式碼會變的整潔，體現出你的程式碼素養...

5、變數、方法、類命名不規範..

     一個程式，命名規範也是很重要的事情，能直接體現你是不是新人..如果看到一個人變數命名不規範，常量小寫，方法名首字母大寫什麼的，開始就可以認為：這個人是新人..你就不能獲得認同感！ 程式設計師就是這樣，只有你能力差不多，別人才會跟你交流自己的想法，你才能學到更多，如果開始你就被認為是新人了..你覺得對方還會跟你交流？

6、關鍵地方不寫日誌

     一個優秀的程式設計師，都會記錄日誌，在很多關鍵的地方，這樣在出現異常，或者檢視部分資料的時候，能直接了當的知道...而不用繁瑣的去檢視程式碼，或者猜測哪裡出了問題...

暫時就寫到這裡...以後補充....千萬千萬不要做那些讓人痛恨的事情~   

本文允許轉載，但必須標明原文和作者出處