软件工程-JAVA应该如何组织一个中小规模的Maven项目

大部分企业构建的代码都属于一个中小规模...

本文不讨论超大规模代码的组织问题，只讨论一个非常典型的JAVA MAVEN工程(后端），以一种语言为主的情况。

 

一、定义pom.xml

在一个典型的maven工程中，通常会存在几个部分：

1.主体-M

2.子模块-A,B,C,D...

3.外部依赖（其它开源或者非开源代码，非本项目所编写)

为了方便我们一般会在M的pom.xml中完成：

a.依赖管理-统一定义所有模块所需要的外部依赖，从而避免版本冲突和重复操作

b.定义子模块

c.项目所需要依赖的自定义仓库

其中统一依赖管理至关重要，现代的ide会帮我们地完成依赖管理。

二、命名

某种程度上，程序设计中，如何合理地命名是一件很头痛的事情，比大部分的crud都让人烦恼。

好命名的唯一标准：看起来通俗易懂，能够让维护人员快速看懂.

关于如何命名这个有个大概的标准：

1.所有人保持一致性，这是最重要最核心的标准

哪怕这个标准看起来很蠢，很操蛋！

统一的标准意味着平等，平直。平等，则大家不容易产生怨言；平直，则不用费劲去理解，是所谓的路径依赖，大大减轻大脑的负担。

标准应该尽量详细，成员有义务去阅读和理解并执行。

凡是项目规范都不读的人，不遵守的人，通常情况可以立刻扫地出门，一刻也不要犹豫。因为此类人不是很傻就是来捣蛋的。

所以，这为什么项目开始的时候，要制定一个详细的统一标准。

 

2.尽量遵循公共标准，便于大部分人阅读

首先这样便于新人的加入，当然针对的是有基础的新人；其次如果你的代码要开源，这是很关键的，太丑陋都不好意思开源。 

 

3.具体某个标准应该保持一致风格

例如：

书写-类名用大峰驼，变量名用小峰驼.不应该既有峰驼也有蛇形的

方法名-大体上遵循 动词+名词格式，或者一个动词、形容词也可以，避免但用一个名词。因为从对象设计角度触发，每个对外的接口都是为了完成一件事情，而做一件事情通常阐明两点：什么动作，什么目标。

     我最讨厌接口方法就是一个名词的。

     如果是一个动词，应该能够通过结合对象名称和方法的方式明确方法的用途。例如一个Paint类，有个方法draw，这个就很清晰了。 如果是一个Shoe类加一个draw难免有点摸不着头脑，需要好好看下代码。

 一个类方法命名示例:

public class Student{
   private String no;
   private String name;
   private String sex;
   public void learn();  //单单一个动词
   public void leaveSchool();   //动词+名词
   public boolean isExcellent();//助动词+形容词
   public void food(); //这个是很糟糕的。莫名其妙。食物？ 吃东西还是卖食物还是...，浪费精力
   public void flow(); //有点糟糕，flow什么?
   public void isShaoshuMingzu();  //英汉混合，不好！
}

 

这仅仅是类的命名，还有文件、变量、表格、字段、样式等等...，不一一列出，原则都是类似的。

 

链式风潮

现在有一种风潮 ：函数式，某种程度上可以称为链式编程

这种风潮的就是不停地点，此外就是方法名变得不合理 ，很有一些人喜欢使用名词作为方法名。

个人建议喜欢这种风格的人应该注意几点：第一这个链式用于设置对象实例属性还是不错，其它不要滥用；其次设置属性的方法建议改为withXXX 

 

4.偶尔也允许一些独特的

有的时候，可能需要对接一些外部api，而这些api还有行业的习惯命名，这个时候偶尔超标也是可以的。 这好比我们遇到了一个知名人物，可以按照特殊情况来称呼对方。

 

三、设计一致性

所谓设计一致性（不含命名）指的是类似的事情应该都按照一套标准来做。

• 例如一个crud需要包含几个文件：mybatis.xml,实体类,mapper,service,imp,controller。
• 不能有的crud没有独立的dao部分，而有的有。
•   或者有的地方dao用mybatis,有的地方用mybaits，有的地方用原生jdbc。

注：特殊情况总是有的，但要有可以成立的情况，例如为了极致性能，为了...

 

四、良好模块划分

如果项目比较大，那么比较有义务把一个大的maven工程分为几个小的工程，这样的好处是：

1. 代码比较容易找，这对后期维护有利。当然在开发过程中也有好处
2. 能够适当提升设计的几个标准（例如SOLID原则),减少耦合和复杂性，提高复用和可维护性

 

按照时下流行的划分方式，通常可以这么做：

1. 底层通用模块common,通常也具体的业务关系不大，倾向于工具性
2. 一个工具类模块tool-可以引用common
3. 一个业务通用模块business-common，主要是实体，POJO，接口定义，配置。便于各个模块之间互相访问
4. 业务模块若干business-x，通常会引用tool和business-common
5. 一个主模块，会引用tool,business-common和business-x之类
6. 其它模块

这些模块之间的关系大体如下图：

 

注：

1.上层模块依赖于下层模块

2.business-x之间通过business-common调用彼此的接口、实体等.它们之间不应该互相引用

业务模块(business-x)应该分为多个，要看需求而定，看个人习惯而定  。大体上业务多那么个数就多，但不要过多，也不要过少。 凡事难在度的把握上。

 

五、小结

1.一个好的框架，一个好的规则对于产品和项目的顺利进行通常具有很积极的影响

2.团队中如果存在经验丰富的工程师，则应该让他来主导规范地址和框架设计。

3.如果团队都是没有什么经验的人，只能自求多福了

4.千万不要迷信网上的一些开源项目的代码质量。既有许多不错，也有很垃圾的。 好的大家都知道，例如spring,Netty。

阿里的代码写得不怎么样！最近看那个fastjson的写得更烂了，不但注释少，还用上了lombok之类的，很难于想想一个广泛使用的组件使用lombok。所以我已经决定要把fastjson从项目中移走。

 

先这样了。后面有再补充