我這幾天終於明白爲什麼說“一個軟件產品的80%的生命期是在維護”。“金九銀十”，這段時間師兄師姐們都去找工作了，研究所遺留系統的維護工作就交到了我的手上。
我一開始還是蠻高興的，因爲覺得又可以學點東西了，但是當我部署完看到代碼的那一剎那，我想死的心都有了。
系統的包大部分是以人名命名，其中還摻雜着業務名，代碼也寫的“東倒西歪”。結果我改了幾天，大致代碼能看了，哎，都是淚。結合前幾天看了一個公司的項目結構，發現分包分的也是不太好（dao層的東西全寫在service裏，並且model、action、service全在一個包下面），所以想着寫篇博文，鞭笞自己以後一定要做到代碼至少“能看”，畢竟良好的代碼風格，提高了代碼的可讀性、持續性和易維護性，使後人能更容易的理解和維護。 廢話不多說，結合實際說說我看重的幾點代碼風格吧。
a.文件命名方式
英文命名：無論是包名還是文件名，都進來用英文簡稱、不然別人怎麼理解。比如“zcgl”你能想到是“資產管理”相關的業務嗎？
駝峯：類裏面定義的一些變量最好也用英文簡稱，並且使用駱駝式命名法，如userInfo,userLogin。
b.項目結構，分包
一般來說，開發一個項目的時候這方面都是項目組長規定好的，但是平常也應該養成這個習慣，畢竟碼奴也是可以夢想當架構師的嘛，哈哈~
現在都強調MVC，所以我一般分包這三層肯定是分開的，比如ssh項目，後臺會分成action、dao、model、service（當然內部可能還有impl之類的包，這裏就不細說）。
一些工具類則可以放在util包裏面，全局調用的類也可以新建個包，比如exception,interceptor之類的。
前臺的主要就是css,js,image,jsp之類的會分開
總的來說，好的分包可以幫助你更快的理解項目結構、查找文件等等，那你又何樂而不爲呢？c.註釋
這一點我不說相信大家也都應該能做到，但是我說下我的一些“潔癖”：
儘可能的使用Javadoc註釋(在類和方法上，使之能最小化)；
多使用塊註釋/**/，少使用//註釋, 除非一些特殊的情況，如變量聲明；
方法上面基本上肯定要有註釋（這樣在一些開發工具裏面，不用打開文件就能看到這個方法的作用）。d.代碼美觀
好吧，這裏我有強迫症，我偏要把代碼對齊、縮進、多餘的空行和無用的引用包刪掉。當然除了這些，有些代碼如sql語句太長、html語句太長，則都是建議換行的。
哎，不說了，吐槽結束！歡迎大家一起吐槽，嘿嘿~