如何编写高质量的代码

1，首先对原有系统要有充分的认识

    根据自己负责的内容，了解它们的业务场景，客户要这些功能的原因。

    从页面上一个一个的点，看看大概是怎么玩的，每个业务，都有一定的关系，流程。需要画个大概的图。

    了解好业务功能后，要了解系统的整体业务架构和技术架构。

    根据原有系统的设计逻辑，梳理各个表的结构，字段的含义，相关表的关系，表写入数据的时机，更新的时机和对应的规则。

    在了解这些的时候，也要画出对应的图。把其中不明白的做好笔记。

   然后看系统对这些业务代码是怎么实现的，可以自己拉个分支，打好注释。对其中不太明白的，或者说比较重点的，需要打断点去分析。

   这里也要把一些看不懂的，有疑惑的，做好笔记。

   最后，拿着前面的图，前面的笔记尽量一次性去找同事确认和解惑。

   达到的效果是，明确90%的业务从前端到后端到数据库整个流程。 内心随便一问某个业务的时候，都能够明明白白，它的业务场景是什么，它是怎么实现的

   它的数据变化如何，它能做什么，不能做什么。

   这里没有太多的诀窍，就是多看，多理解，统一性的找同事，这是后续开发新需求的基础。

 

2，新需求先业务分析

      首先业务是为客户服务的，所以应该真正了解客户的需求是怎么样的，为什么要这个功能，它的场景是什么样的。
      一种办法是找产品经理，业务专家仔细分析。一些比较核心的，甚至要亲自和客户打交道。

      其次，并不是客户的需求都是要实现的，要结合系统的特性，看看属不属于边缘功能，或者当前系统能不能通过其他几个功能的组合就能实现。 

3，制定技术实现方案

     根据我们已有的系统，已有的业务和产品的设计方案，进行技术方案的设计。主要任务是，保证方案行得通，过程是对的，一定要把细节点解决完，特别可能出现的问题，不然当编码的时候发现行不通，导致推倒重来：

     案例： 2019年，笔者根据用户服务，需要做一个全量客户实时消息通知的功能。我们客户分为ABCD四个渠道，在设计的时候，由于我们本身负责A渠道的原因，我们就仅仅用A渠道的数据去做，但是A不包含BCD渠道的，这导致功能都快开发的差不了，发现该问题，导致推倒重来，要打通ABCD渠道。

                 2020年，笔者需要对单据和库存两个微服务对接，单据分为提交，生效等状态。库存根据这些状态锁，加，减库存。在设计的时候，并有按照一个单据只有提交锁库存后才能在生效释放预留的原则来设计。在提交后，直接异步MQ通知库存，此时单据已成功。那么就可能存在，用户提交后，库存还没来得及锁，又立刻生效单据，从而导致生效失败。于是又推倒重来，提交使用同步方案。

     制定技术实现方案的时候，一个是要考虑后续有没有类似的功能，如果有要考虑通用性，扩展性。

     备注：如何避免过度设计呢？其实还是按照业务来设计，要识别出哪些是变的，哪些是不变的。比如订单需要一个支付服务。对订单来说，是不需要去管有哪些支付方式的，应该有个统一的接口。但是对支付服务，那就需要考虑扩展性，可能目前仅仅对接微信，那么未来可能还要对接支付宝，银行等等。那么订单要注意，可能出了我们系统的订单，可能还要第三方的订单，在设计订单流程的时候，要考虑一定的通用性。

     引入新技术的时候，一定要对它有非常深入的认识，知道它有哪些陷阱，能做什么，不能做什么，这一点非常重要。

     案例：2020年，公司引入roketMq，但是没有足够的认识，期间出现过消息重复，发送消息失败抛异常，分布式事务具体该如何编写代码等等问题导致线上出现莫名其妙的BUG。并不是排斥新技术，而是要谨慎。

     对微服务核心功能对接的时候，下游可以设计请求之类的日志表，方便后续排查问题

     案例：2020年单据和库存对接，库存把单据请求的记录存储起来，排查问题的时候，借助日志表，准确的定位出事上游参数传错等问题，缩短了问题排查周期

     还要考虑到对原有系统的冲击:一个原有代码逻辑，一个是老数据

     案例：2019年，笔者针对有用户选座信息进行夸业务线DB缓存，后续选座信息都在该DB去查询，但在缓存的时候，只考虑了以后的客户，但是没有考虑前几天购票的用户，导致当天那些购票的人选座失败，引发严重的生产事故，电话，投诉，修数据。。。。

    
     还要关注下高可用问题，性能要求

     案例：2020年，笔者设计智能请货功能（原本生产有一个类似功能），写入数据量比较大，因为TIDB事务限制，导致写入失败，从而用户获取不到数据。应该把原本类似的功能，也暴露给用户，当智能补货失败的时候，用户还能通过这个方案去获取数据

    最后，要有一套业务监控方案。

    比如A表减库存，B表加库存，那么应该写个sql，来校验两者数量是否守恒。

   案例：2020年，笔者设计库存，利用领导制定的业务sql监控方案，生产环境做到99%用户数据处理无问题，1%的问题能在10分钟内定位问题和制定解决方案。

4，定义好数据结构（表，类）和上下游接口

     命名一定要标准，一般公司有字典，叫法要一致，不要按照自己的方式来。
     一般先是定义好数据库表和具体的字段，其次是建立好类，

    如果上下游对接，要先把交互的数据结构定义好给对方，有些不确定的字段，后续再添加。还要定义好接口
   入参，返回值等等。
    

5，进行编码

     首先要做好参数校验，哪些字段是必传的，哪些字段的取值范围（比如枚举）是否非法，明细的list能否为空，幂等校验等等。

     类名，方法名一定要标准，要见名知意。

     整个结构要清晰，逻辑要清晰，代码要简洁，做到关注点分离。
     一个类职责单一，一个方法职责单一。
     接口的入参要打印日志，关键点要有日志，错误日志描述要准确的反应问题，后续排查的时候

    案例：笔者在设计库存不够锁预留的时候，把对DB的数据和需要占的数据，打印在日志中，能够非常快速的排查问题。
    

6，写好单元测试进行自测（冒烟测试）

     功能写好后，进行自测，测试范围，先是主流程，然后是自己想到的一些组合情况。一般我写完会有些BUG，往往是因为自己粗心导致的，单元测试就能发现这些问题。这样提测的时候，就少很多了。

     案例：笔者在写mybatis mapper sql时候，比如order_id字段，在DB该使用order_id，在Java该使用 #{orderId}，有时候就搞反了。

               拼接的时候少了一个逗号。还得再努力。。。

     涉及别的服务的，使用mock配合测试。

 

7，对接上下游

     根据日志表，接口入参的日志，观察数据是否正常

8，提测---总结有没有遗漏的

         如果对原有的代码有修改，那么提测时候，也要告知测试人员。

        这个时候，再回过头来，再看看功能是否达到预期。

9，生产发布，自己再验证

     评估发版的影响范围，是否需要灰度，一般核心的功能是要的。

     整理好发版的分支，发版的配置，发版的sql(建表，修改表等等)，其次还要注意发版的顺序

     生产发版后自己再到生产环境用测试账号，再试试。

 

10，复盘和总结

      修复完问题后，不能够就不管了，这可是成长最宝贵的经验，每次出现问题，就要进行复盘，看看当时为什么没有考虑到，是自己技术薄弱，还是考虑不周全，还是马虎大意。

      然后进行总结，对症下药。

      最后，每个人都不可能不犯错，要做的是尽最大限度去减少犯错的概率！