编程风格
<h1>编程风格</h1>
<h2>1 接口定义常见问题</h2>
<ol>
<li>返回格式不统一。同一个接口，有时候返回数组，有时候返回单个；成功的时候返回对象，失败的时候返回错
误信息字符串。</li>
<li>没有考虑失败情况。不返回任何数据或者只返回bool类型数据。</li>
<li>出现和业务无关输入参数。</li>
<li>出现复杂的参数。不允许出现例如json字符串这样的参数，这种参数可读性极差。应该定义对应的实体bean。</li>
<li>没有返回该返回的数据。新增接口一般情况下应该返回新对象的id标识。
<h2>2 Controller规范</h2></li>
<li>统一返回ResultBean对象。没有统一格式，AOP无法玩，更加重要的是前台代码很不好写。</li>
<li>ResultBean不允许往后传。ResultBean是controller专用的，不允许往后传！往其他地方传之后，可读性立
马下降。</li>
<li>Controller只做参数格式的转换，不允许把Json，map这类的对象传递到service中去，也不允许service返回
json、map这类数据。要定义实体bean。</li>
<li>如无必要，尽量不要出现Request、Response这类对象。</li>
<li>不要打印日志。日志在AOP里面会打印，而且我的建议是大部分日志在Services这层打印。
<h2>3 日志打印</h2></li>
<li>日志打印最少要满足两个要求：是哪台机器打印的以及用户做了什么。</li>
<li>是哪台机器打印可通过nginx配置来实现，在location中配置add_header。</li>
<li>用户做了什么一般需要打印用户信息，可通过MDC类实现。</li>
<li>其它要求：修改（新增）操作必须打印日志；条件分支必须打印条件值；重要参数必须打印；数据量大的时
候必须打印数据量大小。</li>
<li>建议：不要依赖debug，要依赖日志分析；开发完之后不要着急提交，跑一遍看日志能否看懂。
<h2>4 异常处理</h2></li>
<li>定义好异常处理，异常继承者RuntimeException。</li>
<li>尽量少捕获异常，异常都抛到Controller层用Aop处理。</li>
<li>少加空判断，加了空判断就要测试为空的场景。
<h2>5 工具类编写</h2>
<h3>5.1 隐藏实现</h3>
<ul>
<li>定义自己的工具类，尽量不要在业务代码里面直接调用第三方的工具类，这也是解耦的体现。</li>
<li>自定义工具类的好处有：1.避免不同的人使用不同的工具类库，造成混乱；2.将来需求变动要修改工具类的实
现逻辑，只需修改自定义的工具类即可，不用去每个调用的地方都做修改。既减少了工作量还降低了风险。</li>
</ul></li>
</ol>
<h3>5.2 使用父类/接口</h3>
<ul>
<li>利用抽象的思想，修改参数类型。方法就是往上找接口/抽象类，一直到顶为止，然后把参数类型修改。这样
写出的方法更具通用性。
<h3>5.3 使用重载编写衍生函数组</h3></li>
<li>编写多个重载函数，实际上的代码主体只有一份，但提供各种类型的形参，这样调用起来很方便。
<h3>5.4 使用静态引入</h3></li>
<li>工具类的一个问题就是容易泛滥，主要原因是开发人员找不到自己要用的方法，就自己写一个，开发人员很难
记住类名，所以要让开发人员容易找到，我们可以使用静态引入。
<h3>5.5 物理上独立存放</h3></li>
<li>把工具类代码放到独立的工程或者目录，在物理上要分开，专人维护。有助于保证代码的纯洁和质量。这样普
通的开发人员就不会随意修改。
<h2>6 函数编写</h2>
<p>编写简单的函数是一件简单又困难的事情。简单是因为这没有什么技术难点，困难是因为这是一种思维习惯，很
难养成。</p>
<h3>6.1 不要出现和业务无关的参数</h3>
<h3>6.2 避免使用json/map这样复杂的对象作为参数和结果</h3>
<h3>6.3 有明确的输入输出和方法名</h3>
<h3>6.4 把可能变化的地方封装成函数</h3></li>
<li>编写函数的总体指导思想是抽象和封装，你要把代码的逻辑抽象出来封装成为一个函数，以应对将来可能的变
化。以后代码逻辑有变更的时候，单独修改和测试这个函数即可。</li>
<li>如何识别可能变的地方，多思考一下就知道了，工作久了就知道了。</li>
<li>这一点非常重要，做好了这点，大部分的小的需求变更对程序员的伤害就会降到最低了！毕竟需求变更大部分
都是这些小逻辑的变更。
<h3>6.5 编写能测试的函数</h3>
<h2>7 配置规范</h2>
<h3>7.1 配置文件编码禁忌</h3></li>
<li>读取配置的代码和业务代码耦合在一起</li>
<li>开发初期就定义配置文件</li>
<li>手工编写配置文件
<h3>7.2 重要思想</h3></li>
<li>不要直接和配置文件发生关系，一定要有第三者（这里是配置的bean）。你可以说是中间件，中介都行。 否则，
一开始说用xml配置，后面说用json配置，再后面说配置放数据库。就会做很大的改动。
<h2>8 如何应对需求变更</h2>
<p>正是因为需求变更不可避免，所以我们才更应该把代码写简单，以对付各种各样的需求变化。</p>
<ol>
<li>把代码写到最简单</li>
<li>把可能变化的封装成函数</li>
<li>先做确定的需求</li>
<li>解耦
a) 解耦是编程里面重要的思想，解耦的关键在于：多引入“第三者”，不要直接发生关系。</li>
<li>数据结构上要考虑扩展</li>
<li>
</li>
</ol></li>
</ul>