总结2019

技术

coding

1. 先思考整个逻辑，后将逻辑拆解，分层设计（view/service/持久层）层与层之间交互的api定义，不要着急去实现某一小块逻辑
2. 用简洁的代码将多个api串起来，此时应该知道每个api大致要实现什么功能，思考每个api定义是否合理，包括：

• 是否每个api做到了单一指责原则，下层api应该做到对上层api一无所知
• 对需求进行想象中可能的扩展，扩展后单个api是否能复用，即可扩展性
• api签名是否合理，函数名表达「做了什么事情」，参数则表达做这件事情「需要哪些信息」，是不是每个参数（包括类型定义）对于这件事情都是必须的，能否让cr的人一眼就看懂
• api是否是可测试的。具体逻辑举例：将db中的数据按某些查询条件组装起来，后按某一复杂的业务逻辑合并数据。如果该逻辑被实现在一个方法里面，会很难对方法测试，查db其实就是一段sql，真正想测的是「复杂的合并数据逻辑」，因此这里应该定义成两个方法：抓取数据和处理数据，这样即可mock从db中拿到的数据，专心测合并逻辑。对于复杂的sql查询，可基于docker构造ci数据进行测试，也只测sql的正确性，不应该和「复杂的合并数据逻辑」混在一起

3. 实现定义好的api，此时应注意：

• 方法实现不能过长。过长的方法意味着大量的临时变量，且每个临时变量的作用域贯穿整个方法，这样的代码很难读，也很难改。此时应将逻辑分段成方法，方法签名即注释，让每个临时变量的作用域尽可能短，用完即回收，这也是一种低耦合的思想：若临时变量A与一段相对独立的逻辑无关，尽量不让变量A能在这段逻辑中被访问（控制变量A的作用域）；循环嵌套也不应过深。用break/continue代替else，或将循环体抽成方法
• 当某个对象（一个简单的vo）的（相似/相同）处理逻辑出现在代码里面的多个地方时，从面向对象的角度考虑是否这些逻辑是否应该被抽象成对象的行为（方法）

4. 对核心/复杂易错的逻辑编写单测，单测的意义在于保护既有逻辑的正确性，可能需要单测的地方

• 复杂的sql查询
• 一段包含很多if/else/for循环的逻辑
• 系统核心逻辑（出bug影响面较大的地方）
• …

5. 不要过早的进行性能优化。按照正常的逻辑思路，平铺直叙的实现代码，可读性相对高。当因担心接口耗时慢而增加「并行逻辑」/「缓存逻辑」后，可读性必然降低，但有时这些优化并不见得一定会派上用场；对于数据量大/qps高的接口，上线前做好压测，借助工具or日志分析耗时并针对性优化
6. 适量打log用于定位问题

微服务设计相关

1. 拆分服务，考虑的点

• 单个服务内部维护的数据应该形成闭环，外部服务不该越过服务直接读写表
• 尽量避免分布式事务，能结合业务特点设计写接口的幂等性，retry解决数据不一致的问题
• 可从资源占用的角度拆分访问量大和小的服务，分配不同的资源；从服务稳定性要求的角度拆分核心与边缘服务，避免边缘业务拖挂核心业务
• 服务间若存在接口的相互依赖，思考服务拆分（边界划分）对不对
• 控制服务的数量，多一个服务意味着多一个仓库，多占一份运行的资源，多要一分运维的精力

2. 服务间api的设计，类似服务内层与层之间api的设计，低耦合，对调用方的逻辑一无所知。api定义一旦暴露出去就必须向前兼容，一定要考虑api定义的可扩展性，也要保证api签名语义清晰
3. 公共资源查询逻辑放在sdk，还是rpc，sdk的优势在于调用不走网络，稳定性更高，且少一个服务，rpc的优势在于逻辑的改动能及时被调用方感知，资源隔离

• 查询逻辑简单，较少变动，查询数据量较大（受不了网络传输耗时）适合放在sdk
• rpc调用时，考虑是否存在调用超时的可能，如果可能，要么模拟线上数据量进行压测，要么上线之初timeout设置大一点，再根据情况做调整
• 查询逻辑复杂易变，需要鉴权/监控/审计等功能，抽成服务并提供rpc调用
• 从微服务各模块间交互的角度来看，sdk处于「全局变量」的位置，所有的服务都会与其耦合。往sdk中加代码容易，减代码特别困难

4. 敏捷开发，设计先落地来满足当前的需求，并考虑可扩展性，后逐步优化调整（设计方案时需要综合考虑当前的人力/时间等资源以及可接受的预期）
5. 设计功能的同时，考虑将来维护的成本，数据结构的设计比逻辑设计重要得多：逻辑好改，数据难刷

与PM沟通

• pm和rd的思维方式不同，同样一个业务名词放在一段话中，pm和rd理解的可能不一样。沟通尽量「书面化」，涉及的业务名词用‘「」’标出，多用「因为」/「所以」/「为了」/「如果」/「那么」等逻辑词，这样有助于对方精准理解一段话是在说什么，同时这样也利于消息的转发（信息的传递）。通常一个需求会涉及到多方人员，如果两方的交流过于口头，第三方在之后想要参与进来，理解上下文是比较困难的，往往又需要大量的时间对齐认知

• 对业务名词的认知（定义）在沟通的开始就应该拉齐

• 尽量举例说明问题，避免模棱两可

• 理解prd时，多问为什么，如果不这样做会有什么影响，换种方式（从实现成本考虑）行不行。理解用户的原始诉求，当两个人最终的目的（为用户解决问题）一致时，沟通起来会顺畅许多

待续…