一、目录结构：

后端：

业务相关代码集中写在 com.jeeplus.modules 下面，根据业务模块分包，包下分为：entity，web，service，dao

sqlxml文件集中放在 resources/mappings 下，结构根据 com.jeeplus.modules 保持一致

配置文件集中放再 resources 文件夹下与mappings文件夹同级

前端：

PC端代码统一放在 webContent/webpage/modules 下面

APP端代码统一放在 webContent/webpage/mobile 下面

二、命名规范问题：

包的命名　 （全部小写，由域名定义）

Java包的名字都是由小写单词组成。但是由于Java面向对象编程的特性，每一名Java程序员都 可以编写属于自己的Java包，为了保障每个Java包命名的唯一性。在最新的Java编程规范中，要求程序员在自己定义的包的名称之前加上唯一的前缀。

由于互联网上的域名称是不会重复的，所以程序员一般采用自己在互联网上的域名称作为自己程序包的唯一前缀。 

例如：com.springboot.entity

类的命名 （单词首字母大写）

根据约定，Java类名通常以大写字母开头，如果类名称由多个单词组成，则每个单词的首字母均应为大写。

例如：TestPage

如果类名称中包含单词缩写，则这个所写词的每个字母均应大写。

如：XMLExample

如果类的设计是用来代表对象的，那么命名类时应尽量选择名词。 　　 
例如： Graphics

方法的命名 （首字母小写，字母开头大写）

方法的名字的第一个单词应以小写字母作为开头，后面的单词则用大写字母开头。 
例如：drawImage

常量的命名 （全部大写 ，常加下划线）

常量的名字应该都使用大写字母，并且指出该常量完整含义。如果一个常量名称由多个单词组成，则应该用下划线来分割这些单词。 
例如：MAX_VALUE

Javadoc注释

在每个程序的最开始部分，一般都用Javadoc注释对程序的总体描述以及版权信息，之后在主程序中 可以为每个类、接口、方法、字段添加 Javadoc注释。

每个注释的开头部分先用一句话概括该类、接口、方法、字段所完成的功能，这句话应单独占据一行以突出其概括作用，在这句话后面可以跟随更加详细的描述段落。

在描述性段落之后还可以跟随一些以Javadoc注释标签开头的特殊段落，例如上面例子中的@auther和@version，这 些段落将在生成文档中以特定方式显示。

类注释：

/** 
* 商户相关接口
*  
* @author linjinp
* @version 0.1, 10/11/2002 
*/

方法注释：

/**
* 根据关键字对商户ID与商户名进行过滤
* 
* @param keyword 关键字
* @throws 抛出异常
* @return 方法返回值
*/

变量的命名

主要的的命名规范有以下三种：
Camel 标记法:首字母是小写的,接下来的单词都以大写字母开头
Pascal 标记法:首字母是大写的,接下来的单词都以大写字母开头
匈牙利标记法:在以Pascal标记法的变量前附加小写序列说明该变量的类型

在Java我们一般使用匈牙利标记法，基本结构为scope_typeVariableName，它使用1-3字符前缀来表示数据类型，3个字符的前缀必须小写。

前缀后面是由表意性强的一个单词或多个单词组成的名字，而且每个单词的首写字母大写，其它字母小写，这样保证了对变量名能够进行正确的断句。例如，定义一个整形变量，用来记录文档数量：intDocCount，其中int表明数据类型，后面为表意的英文名，每个单词首字母大写。

这样，在一个变量名就可以反映出变量类型和变量所存储的值的意义两方面内容，这使得代码语句可读性强、更加容易理解。 byte、int、char、long、float、 double、boolean和short。

数据类型/前缀(附)
byte b
char c
short sh
int i
long l
char c
string s
float f
double d
hashtable h
[] arr
List lst
Vector v
StringBuffer sb
Boolean b
Byte bt
Map map
Object ob

对于在多个函数内都要使用的全局变量，在前面再增加“g_”。例如一个全局的字符串变量：g_strUserInfo。

在变量命名时要注意以下几点：

A. 选择有意义的名字，注意每个单词首字母要大写。

b. 在一段函数中不使用同一个变量表示前后意义不同的两个数值。

c. i、j、k等只作为小型循环的循环索引变量。

集合、数组 应该从命名中体现其复数的含义，例如加后缀s或前缀some，名字要有意义。

临时变量通常被取名为i，j，k，m 和n，它们一般用于整型；c，d，e，它们一般用于字符型。

避免用Flag来命名状态变量

用Is来命名逻辑变量，如：blnFileIsFound。通过这种给布尔变量肯定形式的命名方式，使得其它开发人员能够更为清楚的理解布尔变量所代表的意义。

如果需要的话，在变量最后附加计算限定词，如：curSalesSum。

命名不相包含，curSales和curSalesSum。

static final 变量(常量)的名字应该都大写，并且指出完整含义。

如果需要对变量名进行缩写时，一定要注意整个代码中缩写规则的一致性。例如，如果在代码的某些区域中使用intCnt，而在另一些区域中又使用intCount，就会给代码增加不必要的复杂性。建议变量名中尽量不要出现缩写。

通过在结尾处放置一个量词，就可创建更加统一的变量，它们更容易理解，也更容易搜索。例如，请使用 strCustomerFirst和strCustomerLast，而不要使用strFirstCustomer和strLastCustomer。常 用的量词后缀有：First（一组变量中的第一个）、Last（一组变量中的最后一个）、Next（一组变量中的下一个变量）、Prev（一组变量中的上 一个）、Cur（一组变量中的当前变量）。

为每个变量选择最佳的数据类型，这样即能减少对内存的需求量，加快代码的执行速度，又会降低出错的可能性。用于变量的数据类型可能会影响该变量进行计算所产生的结果。在这种情况下，编译器不会产生运行期错误，它只是迫使该值符合数据类型的要求。这类问题极难查找。

尽量缩小变量的作用域。如果变量的作用域大于它应有的范围，变量可继续存在，并且在不再需要该变量后的很长时间内仍然占用资源。它们的主要问题是，任何类 中的任何方法都能对它们进行修改，并且很难跟踪究竟是何处进行修改的。占用资源是作用域涉及的一个重要问题。对变量来说，尽量缩小作用域将会对应用程序的 可靠性产生巨大的影响。

关于常量的命名方法，在JAVA代码中，无论什么时候，均提倡应用常量取代数字、固定字符串。也就是 说，程序中除0，1以外，尽量不应该出现其他数字。常量可以集中在程序开始部分定义或者更宽的作用域内，名字应该都使用大写字母，并且指出该常量完整含 义。如果一个常量名称由多个单词组成，则应该用下划线“_”来分割这些单词如：NUM_DAYS_IN_WEEK、MAX_VALUE。

域(Field)命名

字段命名尽量与数据库保持一直，使用首字母小写的驼峰命名法。
public static final 字段(常量) 全部大写，并用下划线连起来。

例子：

   public class MyClass 

   {  

      public static final int SOME_CONSTANT = 42;  

       public int publicField;  

       private static MyClass sSingleton;  

       int mPackagePrivate;  

       private int mPrivate;  

       protected int mProtected;  

   }

三、哪些代码需要重构

臃肿的类：类之所以会臃肿，是因为开发者缺乏对最基本的编码原则，即“单一职责原则”（SRP）的理解。这些类往往会变得很臃肿，是由于不同的且在功能上缺少关联的方法都放在了相同的类里面。

长方法：方法之所以会变得很长主要是有以下几个原因：

        1、许多没有关联性的、功能复杂的模块的代码都放在相同的方法内。这主要是开发者缺乏SRP的概念。

        2、多种条件都放在同一个方法内，这在长方法内经常会发生的。这是由于缺乏McCabe代码复杂度和SRP的概念的比较。

大量的传参： 我经常遇到这几种情况，一些方法跟另一些方法进行交互，或者调用另一些方法的时候传入大量的参数。这就会出现如果更改了其中一个参数，就得在多个方法内进行更改。

常量值无处不在：经常会发现开发者（尤其是新手）会使用一些具有明确含义的常量值（主要是魔鬼数字），但没有给它们赋予合适的常量变量。这会降低代码的可读性和可理解性。

模糊的方法名：许多时候，以下取的方法名会影响代码的可读性和可理解性：

        1、模糊的不具有任何意义的方法名

        2、技术性的，却没有提及相关领域的名称

四、重构的方法

提取类/抽离方法

正如上面提到的，像“臃肿的类”（一个类提供了本该有几个类提供的功能）这种代码异味应该将原有类中的方法和属性移动到适当数目的新类中去。旧类中对应新类的方法和属性应该被移除。另外，有时候一些类过于臃肿是因为它包含了被其他类使用本应该是其他类的成员方法的成员方法。这些方法也应该被迁移到合适的类中。

提取方法

像上面提到的“过长的方法”这种代码异味可以通过从旧方法中提取代码到一个或多个新方法中消除。

分离条件

许多时候，一个方法很长是因为包含好几个分支语句（if-else）。这些分支条件可以被提取和移动到几个单独的方法中。这确实能大大改善代码可读性和可理解性。

引入参数对象/保留全局对象

在我做代码审查时发现另外一个很常见的情况 - 好几个参数被传入方法。问题主要与需要从已有方法中增加或者移除一个方法参数有关。在这种场景，建议将相关方法参数组成一个对象（引入参数对象），让方法传递这些对象而不是每个单独的参数。

用符号常量替换魔法数字

对于有意义的并且到处被使用的字面常量，应该为它们分配一个命名常量。这能大大增强代码可读性和可理解性。

重命名方法

正如上面提到的，模糊不清的方法名会影响代码的可使用性。这些模糊不清的名称应该重命名为有意义的可能与业务术语有关的名称，来帮助开发者通过业务上下文更好地理解代码。这很需要技巧并且要求开发者与业务专家一起协作来理清代码需要满足的业务需求。有趣的是，这种重构方法看起来似乎非常容易理解，但是常常被许多开发者忽视。