即使是技术类工作，除了“专业能力过硬”，以下软素质同样重要！

1. 认真负责

• 不把“出了问题谁负责”挂在嘴边，相反，“就这么干，出了事我负责”更具备leader的潜质
• 交给ta的任何事情，能够拿到结果，如果每件小事都能让人放心。就问你，你踏实不踏实？
• 不推三阻四，很少下意识的“找借口”，如果每次沟通都反馈“不是我”、“我没有”。就问你，你气不气？

一、背景

由图1、图2 可见heap和permGen使用率都不高，但是abc-center 2台机器基本上每天会进行2次规律性的FullGC；

源于线上应用事件

某天团队同学收到线上系统报警，web-abc真线有一台机down掉了。

为保留事故现场，做剩余应用做了dump。

然后开始分析

《一文就让你精通JVM》

网上有关JVM的知识贴多如牛毛，其中有纷杂的零碎知识贴，也有整理优秀的长贴。信息量非常充分。

但作为复习或整理JVM知识的而言，还可以有更好的学习用户体验和高效的方式。因此，就想尝试写一篇有关JVM知识点的“秘籍”，让初学者仅读此文就能快速精通JVM的知识脉络以及关键知识，也能让复习着快速反查知识和经验之谈。

黄老师

API命名规范

命名风格

面向资源

同RESTful命名风格

在大型系统中，常以”业务领域”视角进行模块划分，以达到业务”高内聚低耦合”的效果。

“业务领域”必有”数据对象”沉淀，从宏观抽象的角度看，"数据对象"可统称为"资源"，”业务领域”就是业务相近的”资源”的集合。

API错误返回规范

禁止通过抛异常形式返回API业务错误

API禁止抛Checked异常，即业务处理上的参数错误、逻辑错误、业务错误等禁止通过抛异常形式返回，应用Response#code, message表达业务错误。

注：不要逼调用方到处写try{}catch()。

• 正例：

1

Response<T> saveDesposit(...);

• 反例：

1

T saveDesposit(...) throws ServiceException, IllegalArgumentException, ValidationException;

API版本规范

发布RELEASE版本

正式发布的api包必须是RELEASE版本

eg.

1
2
3
4
5

<dependency>
    <groupId>cn.gov.zcy.paas.template</groupId>
    <artifactId>template-api</artifactId>
    <version>2.1.1.RELEASE</version>
</dependency>

版本号风格

使用 《Semantic Versioning》风格

【强制】字段名称用小驼峰风格

【强制】Service API返回值必须使用Response包装

• Service API返回值强制要求进行通用包装，例如：Response。

• Response的作用：

  1. 统一方法表示API调用是否成功
  2. API调用失败时，统一格式反馈错误Code，错误Message
  3. 统一的Response易于调用方经验复用，框架集成

• 作为API调用方，其编码诉求很简单：

  1. API调用是否成功；
  2. 调用不成功时，提示文案是什么；

• 调用方几不想：

  1. 不想关心API内部有多牛逼
  2. 不想关心API可能会抛的各种Exception，以及因此不得不做各种异常处理

• 关于当前不统一的Response

  • 【新业务】【强制】使用架构组定义的统一Response：ZCY Response
  • 目前业务方有自定义Result/Response，风格和作用大同小异。有更好的设计可以自荐给架构组集成，杜绝各自开辟重复的新定义。

你是否也感同身受？

1. 对接XX业务时，XX业务具备的功能和API全靠跑业务负责人那反复逐个询问、确认。用哪个API；怎么用；有没有限制；等等
2. 各个业务间，甚至同一业务内，API风格不统一。
   • API命名：按自然语义全翻译的；按属性角度定义的；按操作角度定义的；动宾、非动宾的；复数、非复数的；等等
   • API入参：带Map的；相同语义字段名称不一样；
   • API出参：有包装Resoponse的；直接返回结果数据的；相同数据，返回格式和字段名称有差别的；
   • 错误信息：直接返回中文提示的；返回提示信息编码的；返回异常类型的；等等
3. XX业务API性能方面未知。
4. 随着业务的演进，开放的API持续在增加，但类同的很多

JStorm分享-课件资料