代码应该怎么写？

目录

前言

一、行为分析和限定，保证代码健壮性

二、严格控制代码执行流程，保证代码可靠性

代码执行流程 模型图

代码应该怎么写？

1、定义大纲

2、分别对ABC流程进行代码细节填充。

3、其他注意事项

三、优化’原生‘代码，保证代码易读性

优化步骤

四、review代码

总结

---

前言

        如果想要提高自己写代码的水平，对代码有自己的思考，建议大家有时间可以看一下关于代码规范的书籍。

        这是我阅读《代码大全2》写的读后感，可供大家借鉴：《Code_Complete_2》持续更新中......_@来杯咖啡的博客-CSDN博客

        当你读完之后，且在实际项目中已经沉淀了一段时间，再来读读代码规范的文章：

     【开发规范】持续更新中......_@来杯咖啡的博客-CSDN博客

      

         代码规范，只是给我们一个结论，并没有过多的阐述这么些的原因。这些原因我们可以从书中获取到，再结合实际项目中的场景，我们会更好的理解这个结论，从而真正意义上去遵守代码规范。

原则和要素

一个原则：

        ”一切皆为对象，对象源于生活。“

分析器、解析器、处理器.....

三个要素：

        解耦合、考虑复用、方便扩展。     

设计模式...

一、行为分析和限定，保证代码健壮性

行为分析：

        在真正进行编码之前，必须梳理清楚使用方(用户等)的行为。行为就是场景，不同的行为会产生不同的数据结果。我们代码出bug往往是因为‘没有考虑到某个场景’ 而导致程序往 ‘出乎意料’的流程执行。

行为限定：

        以肯定的风格写代码，这就是用户行为限定。我期望的数据入参是什么样的，如果出现我没有预料到的入参，我的程序是不去处理呢 还是 走一个兜底的方案。

二、严格控制代码执行流程，保证代码可靠性

        编码时，始终牢记两个要点：1、主流程 （正向流程） 2、异常监听（逆向流程）。让你的代码执行流程符合你的预期。

代码执行流程 模型图

代码执行流程：1、正常执行； 2、异常执行。

老规矩，首先在脑海中建立一个‘代码执行流程链路’模型：

①主流程：主流程包括ABC三个节点；

②异常流程：异常流程可能在ABC任意一个节点发生，当他发生的时候整个代码执行流程【可能】要改变；

1. 如果该异常和 主业务 无关，可以直接吃掉这个异常然后代码执行流程不变(ABC)；
2. 如果该异常和 主业务 有关，一旦发生则后续流程无法执行(AB)。

思考：

1、C流程会被执行到吗？

-- 不一定。因为A、B其中任意一个发生异常 + 程序中开发人员根据A、B业务重要程度对异常的处理方案 ，可能造成 C执行不到。

2、如何让C流程一定被执行？

-- 对A、B流程进行 异常监听(try catch finally)。 将C流程放到finally里面，或者如果AB流程都没有return操作，C流程可以放到try catch外面。

 // C放到finally里面
      try{
            // 执行A
            ...
            // 执行B
            ...
            return ;
        } catch (Exception e) {
            log.error("error");
        } finally {
            // 执行C
            ...
        }
 
 
 // C放到try catch外面
       try{
            // 执行A
            ...
            // 执行B
            ...
            
        } catch (Exception e) {
            log.error("error");
        }
        // 执行C
        ...

代码应该怎么写？

写代码有个很大的忌讳：上来就开始写 细节 代码。比较正确的写代码方式如下：

1、定义大纲

先定义代码大纲目的是：这是一种 约束。它规定了代码执行的流程；

//1. ‘注释’形式定义代码【正常执行】流程
void m () {
// A
 
// B
 
// C
 
}
 
//2. 根据真实‘业务场景’判断每个流程是否进行【异常监听】,考虑异常时是否【提前结束程序】
     下面代码模拟场景：A流程如果异常直接提前结束程序；B流程出现异常不要影响后续流程；C流程执行且不进行异常监听；
 
void m () {
// A
 
try{
  // B
} catch(Exception e) {
  log.error("error");
}
 
 
// C
 
}

2、分别对ABC流程进行代码细节填充。

3、其他注意事项

（1）能以「编程式」的方式写代码，就不要以「声明式」的方式写代码。比如你想对入参做一个字符串长度校验，推荐使用”if() then“的代码方式，而不是用”@Size(max = 100, message = "字符串校验不通过")“的注解方式。

-- 原因：注解的方式，出问题不好排查。对于远程服务调用，如果注解校验没有通过，你以为会抛出message里面的异常消息，但是很有可能被内部框架拦截，抛出一个内部框架自定义的异常，导致你排查问题时间很长。

三、优化’原生‘代码，保证代码易读性

        代码一定是以【可靠性】为主的，所以我把代码的执行流程放到了首位，这样我们一开始的注意点就是保证代码可靠性。 

        那么，当代码写完之后，我们再开始思考如何让代码看起来更易读。

优化步骤

第一步：将原生代码进行职责拆分。单一职责。

第二步：借助面向对象的方式抽取代码。如果某一块代码职责有点中，可以定义一个分析器、解析器、处理器来抽离代码。

第三步：考虑使用设计模式。即使定义了一个’对象‘，然后发现该对象又做了很多事情，可以考虑使用设计模式。

其他：

1、配置和代码分离。把配置放到阿波罗里面，做到可扩展。

四、review代码

代码写完之后，需要进行review。期望步骤如下进行：

1、高层次 - 以‘流程图’的形式，简述你的设计思路。站在一个高的角度，看其设计有没有问题。因为代码是根据设计来写的，如果设计都有问题，代码肯定有问题。

2、具体 - review代码。在具体review代码时候，需要注意：数据库CRUD操作(之前有博客专讲CRUD注意事项)、数据输入与输出......

忌讳review时，上来就看代码。

总结

思维模式。