（2018）转型Java从0到1技术创业回顾系列（1）

约定定义

在整个开发团队从0到1的过程中，我们也积累了很多刚需的问题。这以后也是我们的不断升华的基石。

1. Header Code定义

规则：2位大系统 + 2位子系统 + 4位业务代码

Eg：

# 20——支付系统，01——控制服务，0001——支付单不存在
20010001

# 20——支付系统，02——订单服务，0002——验证不通过
20020002

与多语言集成最佳实践

首先看看响应结构：

{
  "data": {
    //response's data
  },
  "header": {
    "code": "string",
    "message": "string"
  }
}

字段说明：

• header：响应头部
• header.code：服务端响应的代码
• header.message：消息
• data：数据体

其次，资源文件定义：

messages_en_CN.properties

20011007=取消订单：{0}失败. {1}
20011008=请登陆
20011009=会员不匹配
20011010=订单已过期

messages_en_US.properties

20011007=Cancel order:{0} failed. {1}
20011008=You need login.
20011009=Your member does not match.
20011010=The order has expired.

再定义Code对应的异常，绑定到Code

public class CancelOrderException extends SigmaException {


    public CancelOrderException() {
    }

    public CancelOrderException(String message) {
        super(message);
    }

    public CancelOrderException(String message, Throwable cause) {
        super(message, cause);
    }

    public CancelOrderException(Throwable cause) {
        super(cause);
    }

    public CancelOrderException(String message, Throwable cause, boolean enableSuppression, boolean writableStackTrace) {
        super(message, cause, enableSuppression, writableStackTrace);
    }

    @Override
    public String getErrorCode() {
        //public static final String CANCEL_ORDER_FAILED = "20011007";
        return ResponseCodes.CANCEL_ORDER_FAILED;
    }
}

最后，抛出异常：

throw new CancelOrderException().withArguments(orderId, getOrderStatus);

2. Redis变量定义

系统简写	分割符	中缀	后缀
{source | projectCode}	分号	{orderId}:不同的流程后缀	香蕉:{orderId}

Eg:

• trp:12345:lsf
• trp:12345:prc
• trp:12345:booking
• kount:order:1234
• kount:order:1245
• paypal:expiry:123
• paypal:expiry:124

3. GIT提交规范

格式：

类别#ID 分支 操作 desc:描述

• 类别：task,story,bug, issues。task:指禅道的任务，story:禅道的需求，bug:禅道的bug ，issues：指gitlab的Issues 。
• ID对应禅道或者Gitlab的ID
• 分支：具体的分支，eg: feature-1.0 或者release-1.0
• 操作：[DEV] [BUG] [REF] 。DEV对应功能开发，BUG对应BUG修复，REF对应重构。
• 描述：突出代码的修改

GITLAB示例：

4. 项目目录结构

优先采用多模块结构

XXX项目层次结构示例：

• XXX——根pom
  • XXX-ms——微服务，提供web API调用
  • XXX-dashboard——站点，提供后台维护
  • XXX-rest——提供Online API，对外，对移动端。
  • XXX-contract——契约，提供Feign调用接口，定义rest或者ms的接口。
  • XXX-common——公共工具
  • XXX-task——任务POM
    • XXX-YYY-task——具体任务1
    • XXX-ZZZ-task——具体任务2
  • XXX-consumer——消费者POM
    • XXX-YYY-consumer——具体消费者1
    • XXX-ZZZ-consumer——具体消费者2
  • XXX-domain——领域层POM
    • XXX-domain-impl——实现层
    • XXX-domain-modeling——建模层

• XXX是项目名
• YYY是子模块名
• 其他的酌情命名

5. GITFLOW + GITLAB

最佳实践：

• Issue + feature’s branch实现功能的不断增强；
  在开发Sigma框架的过程中用得比较多。
• Protect Branches：master、release-*、feature-*、hotfix
  多人协作得时候，广泛使用。
• Set default branch
  方便切分支。
• Set Member Access，限制非管理角色，不能合并到受保护的分支
  让Code Review有专门的人做。
• 及时Rebase
  保证最小的冲突解决
• 提交之前要合并，本地解决冲突，比如，将feature-1.0合并到feature-1.0#task1234
  自治合并
• 一个任务或一个BUG或一个ISSUE，对应一个分支
• 同一个分支可以发起多次合并请求。
• 在可估计的提交次数以内，优先使用rebase。