码代码

日志：#日志# api请求的，请求异常一定要有日志

#异常处理# 封装的异常，要保留原始异常信息，异常堆栈中要能追溯原始异常的堆栈

打日志一个非常重要的点（特别是支付场景）： 在请求前打，请求之后再打，而不是只在一边打

#软件工程师核心能力# 读代码 并不是每个项目都是从零开始的，大多数时候都是给一个现有的仓库做维护，好比给一个房子添砖加瓦、做改造。 如果不了解手头做的事，只追求把自己的那部分做好，不了解改动会对现有系统产生什么样的影响，可能会导致什么后果，就不算是合格的，很可能有一天会砸到自己、碰到别人。 怎么避免呢？依靠对业务的理解和判断（和领域专家、团队沟通），对实现的理解（读代码）。

命名一定要很明确，无论是业务系统，还是技术组件，明确表达是干啥的。 ps: 看见项目代码中各种set_xxx, process_xxx就头大。。。

对扩展开放，#开原则#的应用： 实现sdk的版本迭代时，提供一个最基础的方法，方便用户找不到封装方法时，自己还能在这个最基础的方法上实现一个，达到用户端扩展的目的。

延伸：有依赖关系的且多变的地方，强调简单、灵活。

api设计：简单，傻瓜化，不要指望调用方处理复杂的逻辑。

抽象：从业务角度去抽象代码，而不是实现角度

实际的例子：一个类似优酷的视频平台，现有的服务已经支持了点播视频，现在需要增加一个直播业务，并且产品希望在合理的规则约束下，尽可能复用点播的业务逻辑。 在增加新功能的时候，发现现有实现严重耦合了点播视频的一些东西。 从业务角度抽象代码，背后的逻辑是，代码要合理对现有业务逻辑做抽象，能够在适应新的业务时灵活调整。

抽象本身也是有成本的，技术团队要在扩展现有系统能力的成本、抽象的成本直接做取舍。