近期负责的是公司即将上线的一个项目，半个月前接手项目的时候已经是其他人开发到即将收尾的项目了，接手之后就是要部署上线的。但是至今仍在不断地加班加点的“打补丁”，项目中出现了很多意想不到的问题，也致使项目一拖再拖不能按时上线。现在就罗列一下目前发现的一些问题：
一、命名规范性问题
1、大小写规范不遵守：在项目中，命名混乱，不按照规范命名，包、类、方法、变量的命名大小写随意使用，出现类名称使用小写字母开头、方法和变量以大写字母开头等低级问题。
问题纠正：
包名称：包名统一使用小写，点分隔符之间有且仅有一个自然语义的英语单词。包名统一使用 单数形式。但是由于Java面向对象编程的特性，每一名Java程序员都 可以编写属于自己的Java包，为了保障每个Java包命名的唯一性，在最新的Java编程规范中，要求程序员在自己定义的包的名称之前加上唯一的前缀。 由于互联网上的域名称是不会重复的，所以程序员一般采用自己在互联网上的域名称作为自己程序包的唯一前缀，即反域名作为包的前缀，如小编习惯以自己名字简拼域名作包前缀：com.zj.utils，com.zj.bo，com.zj.bo.impl等。
类名称：根据约定，Java类名通常以大写字母开头，如果类名称由多个单词组成，则每个单词的首字母均应为大 写，类名使用 UpperCamelCase 风格，即“大驼峰”风格，必须遵从驼峰形式；如果类名称中包含单词缩写，则这个所写词的每个字母均应大写，如：XMLExample,还有一点命名技巧就是由于类是设计用来 代表对象的，所以在命名类时应尽量选择名词。
方法名、参数名和变量名：方法的名字的第一个单词应以小写字母作为开头，后面的单词则用大写字母开头，即方法名、参数名、成员变量、局部变量都统一使用 lowerCamelCase 风格，必须遵从“小 驼峰”形式。
常量名：在JAVA代码中，无论什么时候，均提倡应用常量取代数字、固定字符串。也就是说，程序中除0，1以外，尽量不应该出现其他数字。常量可以集中在程序开始部分定义或者更宽的作用域内，名字应该都使用大写字母，并且指出该常量完整含 义。如果一个常量名称由多个单词组成，则应该用下划线“_”来分割这些单词，不要嫌名字长，如：NUM_DAYS_IN_WEEK、MAX_VALUE。
2、不遵守“见名知意”规范
项目中出现单字母或双字母的简单命名现象，更有中英文混搭现象。在阅读代码的时候，还要翻到变量定义的位置查看具体的意义，大大降低了维护的效率。
问题纠正：
为了达到代码自解释的目标，命名的时候要考虑到：
1、坚决不允许出现中文及拼音命名。
2、杜绝完全不规范的缩写，避免望文不知义。
3、任何自定义编程元素在命名时，使用尽量完整的单词 组合来表达其意。
二、修饰词滥用
项目中，在server层的类中，方法被加上了static修饰词，而在controllor层调用的是又使用对象来调用这些方法。这不仅是滥用修饰词的问题，这里也反映出编码者对static的作用不了解或不清楚类加载时构造方法、静态方法、普通方法的执行顺序。这种编码，会使所有方法在加载的时候都已经被加载到内存里等待使用类名.方法名来调用，而编码者却又创建了类的对象去调用，这严重损耗系统资源。
问题纠正：
1、static的意义及作用：
static表示“全局”或者“静态”的意思，用来修饰成员变量和成员方法，也可以形成静态static代码块，但是Java语言中没有全局变量的概念。被static修饰的成员变量和成员方法独立于该类的任何对象。也就是说，它不依赖类特定的实例，被类的所有实例共享。只要这个类被加载，Java虚拟机就能根据类名在运行时数据区的方法区内定找到他们。因此，static对象可以在它的任何对象创建之前访问，无需引用任何对象。static修饰的成员变量和成员方法习惯上称为静态变量和静态方法，可以直接通过类名来访问，访问语法为：
类名.静态方法名(参数列表…)和类名.静态变量名。
2、类中方法的执行顺序：
Java中方法执行顺序：首先是静态块先执行，静态方法，最后是构造函数。构造方法只有在new对象的时候才会执行，静态语句块和静态方法在类加载到内存的时候就已经执行了。另外，静态语句块只能给静态变量赋值，里面不能出现方法，同样，静态方法里面也不能出现静态语句块。先是静态语句块执行，然后静态方法加载到内存，静态语句块你不管它它会自动会执行，而静态方法它一直存在于内存中，只有你用类名点方法名的时候才会执行。
三、分层混乱
项目中的问题：
1、controllor层或server层直接操作dao持久层
2、各层实现类之间直接调用，没有接口
3、出现下一层次调用上层的方法
问题纠正：
所谓的三层开发就是将系统的整个业务应用划分为表示层——业务逻辑层——数据访问层，这样有利于系统的开发、维护、部署和扩展。分层是为了实现“高内聚、低耦合”。采用“分而治之”的思想，把问题划分开来各个解决，易于控制，易于延展，易于分配资源。
表示层：负责直接跟用户进行交互，一般也就是指系统的界面，用于数据录入，数据显示等。意味着只做与外观显示相关的，不属于他的工作不用做。
业务逻辑层：用于做一些有效性验证的工作，以更好地保证程序运行的健壮性。如完成数据添加、修改和查询业务等；不允许指定的文本框中输入空字符串，数据格 式是否正确及数据类型验证；用户的权限的合法性判断等等，通过以上的诸多判断以决定是否将操作继续向后传递，尽量保证程序的正常运行。
数据访问层：顾名思义，就是用于专门跟进行交互。执行数据的添加、删除、修改和显示等。需要强调的是，所有的数据对象只在这一层被引用，如System.Data.SqlClient等，除数据层之外的任何地方都不应该出现这样的引用。
注意：1.层次划分清楚，上层代码只能调用下层代码，下层代码不能调用上层代码。比如控制层代码可以调用业务逻辑层，业务逻辑层可以调用数据访问层等，反过来则不行。
2.每层开发应该使用接口，对外公布接口。当有上层调用的时候，可以修改本层实现，而不必修改调用方的代码。
按照这个指导思想开发，可能会出现以下层次结构划分：
-视图层 -控制层 -业务逻辑层接口 -业务逻辑层实现 -数据访问层接口 -数据访问层实现 -数据存储层
四、方法封装不简洁
项目中出现方法的定义中实现的功能不够单一，方法行数上百的很多，阅读的时候不易理解，来回查看。
问题纠正：
1、单一职责：每个方法实现单一更能
2、行数一般控制在100之内，最好50以内（没有具体定论，视情况而定，这里仅供参考）。
五、吝啬javadoc的使用
项目中的注释地方太少，注释不够规范。给也读带来了极大地不便。
问题纠正：
1、类、类属性、类方法的注释必须使用 Javadoc 规范，使用/**内容*/格式，不得使用 // xxx 方式。
2、所有的抽象方法（包括接口中的方法）必须要用 Javadoc 注释、除了返回值、参数、 异常说明外，还必须指出该方法做什么事情，实现什么功能，对子类的实现要求，或者调用注意事项。
3、所有的类都必须添加创建者和创建日期。
4、方法内部单行注释，在被注释语句上方另起一行，使用//注释。方法内部多行注释 使用/* */注释，注意与代码对齐。
5、所有的枚举类型字段必须要有注释，说明每个数据项的用途。
6、代码修改的同时，注释也要进行相应的修改，尤其是参数、返回值、异常、核心逻辑 等的修改。
7、谨慎注释掉代码。在上方详细说明，而不是简单地注释掉。如果无用，则删除。
8、对于注释的要求：第一、能够准确反应设计思想和代码逻辑；第二、能够描述业务含 义，使别的程序员能够迅速了解到代码背后的信息。完全没有注释的大段代码对于阅读者形同 天书，注释是给自己看的，即使隔很长时间，也能清晰理解当时的思路；注释也是给继任者看 的，使其能够快速接替自己的工作。
未完，待续。。。