我这几天终于明白为什么说“一个软件产品的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语句太长，则都是建议换行的。
哎，不说了，吐槽结束！欢迎大家一起吐槽，嘿嘿~