shadow_zed的博客

正例：错误码回答的问题是谁的错？反例：一个五位数字 12345 ，第 1 位是错误等级，第 2 位是错误来源， 345 是编号，人的大脑不会主动地 拆开并分辨每位数字的不同含义。说明：在无法更加具体确定的错误场景中，可以直接使用一级宏观错误码，分别是：A0001（用户端错误）、【强制】编号不与公司业务架构，更不与组织架构挂钩，以先到先得的原则在统一平台上进行， 审批生效，编号即被永久固定。【推荐】在获取第三方服务错误码时，向上抛出允许本系统转义，由C转为B，并且在错误信 息上带上原有的第三方错误码。

修改为请求头含有X-Encrypt=v1时，网关对请求结果和返回响应进行v1版本加解密算法( 算法为 base64(aes(body)) )，对请求解密和对响应加密。如果 POST /v1/pb/user 需要升级 则将整个微服务/v1升级到/v2, 同时保证版本兼容的api老版本可以继续访问。无法用名词+请求方法表述的可以扩展为 /域对象/动词 例如 POST /user/login。要求兼容上一个版本 如果当前是 /v3 则 /v2 要求可以正常使用 /v1 不做要求。

4、谨慎记录日志，生产环境避免输出debug日志，有选择地输出 info 日志，注意日志输出量的问题，避免无意义的大段不可阅读的日志。5、常量命名全部大写，单词间用下划线隔开，力求语义表达完整清楚准确，细粒度，不要嫌名字长；接口设计应立足于本服务自身，服务核心提供什么对外的能力，接口用于匹配自身的能力，接口设计以通用为准，避免被需求牵着走，提供一大堆极度相似的接口给维护带来困难。3、所有代码：包括项目代码、测试代码、临时性代码、脚本统统加入Git仓库进行版本管理，避免误删除、误操作丢失。

Code Review由项目负责人发起，一个项目过程中至少2-3次，主要集中在项目中后期，如果项目规模较大，功能较多，时间比较宽裕，也可适当增加。1、大型项目，增加/修改超过10个文件或超过500行代码的，需组织CodeReview会议，邀请相关同事及高阶同事参与代码Review。2、小型项目，小需求修改（少于10个文件变更或少于500行代码的），至少需要1~2位同事帮忙进行代码Review并提出点评建议。代码的一致性、编码风格、代码的安全问题、脱敏问题、代码冗余、是否正确设计以符。

使用release发布生产成功后，三日之内把release分支合并到master上并打tag。使用realase分支创建tag版本，使用tag进行线上部署生产流水线自动打tag不接受commit，只接受来自realase分支的merge操作分支必须开启分支保护，只有维护者可以操作可从test/master分支上拉取；不接受commit，只接受来自对应test分支的合并操作；普通开发人员不具有合并权限，需要管理员才能合并release分支用于发布预生产环境部署；上线成功后必须立即。