独泪了无痕

无论是在现实世界中还是在软件系统中，都存在一些复杂的对象，它们拥有多个组成部分，如汽车，它包括车轮、方向盘、发送机等各种部件。而对于大多数用户而言，无须知道这些部件的装配细节，也几乎不会使用单独某个部件，而是使用一辆完整的汽车。而在实际开发工作中，我们经常碰见的 XxxBuilder 的类，通常都是建造者模式的产物。通过建造者模式对其进行设计与描述，建造者模式可以将部件和其组装过程分开，一步一步创建一个复杂的对象。用户只需要指定复杂对象的类型就可以得到该对象，而无须知道其内部的具体构造细节。

在移动互联网，分布式、微服务盛行的今天，现在项目绝大部分都采用的微服务框架，前后端分离方式，前后端的工作职责越来越明确。前端和后端进行交互，前端按照约定请求URL路径，并传入相关参数，后端服务器接收请求，进行业务处理，返回数据给前端。我们可以参考HTTP请求返回的状态码这样的设计，这样的好处就把错误类型归类到某个区间内，前端开发人员在得到返回值后，根据状态码就可以知道，大概什么错误，再根据message相关的信息描述，可以快速定位。@Getter/** 成功状态码 */

在我们对数据库技术方案设计的时候，我们是否有自己的设计理念或者原则，还是更多的依据自己的直觉去设计，是否曾经懊悔线上发生过的一次低级故障，可能稍微注意点就可以避免，是否想过怎么才能很好的避免，下面规范的价值正是我们工作的检查清单，需要我们不断从错误中积累有效经验来指导未来的工作。

目前现有前后端开发模式：“后端为主的MVC时代”，如下图所示：代码可维护性得到明显好转，MVC 是个非常好的协作模式，从架构层面让开发者懂得什么代码应该写在什么地方。为了让 View 层更简单干脆，还可以选择 Velocity、Freemaker 等模板，使得模板里写不了 Java 代码。看起来是功能变弱了，但正是这种限制使得前后端分工更清晰。前端开发重度依赖开发环境，开发效率低。这种架构下，前后端协作有两种模式：一种是前端写demo，写好后，让后端去套模板。

在项目中发现开发小组成员在写程序时，对于 Oracle 数据类型为 Number 的字段、mysql中的decimal字段，在实体映射类型中，有的人用 Double，有的人用 BigDecimal，没有一个统一规范，为此我在这里总结记录一下。BigDecimal，相信对于很多人来说都不陌生，很多人都知道他的用法，这是一种 java.math 包中提供的一种可以用来进行精确运算的类型。