编码意识（一）：在知道和真正理解并运用之间有一个过程

分手后的思念是犯贱 2022-11-14 01:30 102阅读 0赞

#### 背景 ####

1.  从书上看见的，从讨论中获取的，从实践中体会的，从反思中感悟的编码意识。这些经验很好，可是真正能够运用起来却真的需要一个漫长的过程。

#### 过程 ####

*  **抽象与具体编码意识**

1.  销毁一个城市。销毁一个罗马城市。
    
    在具体的实现过程中，写一个销毁城市的方法，将城市名称作为参数传递。
2.  更新一条数据。更新数据的状态为已完成。
    
    在具体的实现过程中，写一个更新数据的方法，把状态作为参数传递。
    
    结论：**我的方法仅仅是“工具”，做一件事的中介，不应该和具体的业务逻辑耦合到一起**。

*  **修改代码的编码意识**

1.  不要去修改原来已有的且正确的业务逻辑过程，除非自己已经完全且深刻理解了整个流程。
2.  如果有新的功能，应该去扩展的方式，也就是添加新的代码写。一般操作过程是：重构一下，然后在写。重构可以是简单的if else之类的。重构的目的：让代码结构更加简单，让新的代码不要修改原来的代码，而嵌入进去。
3.  代码应该给修改的人一点提示，不能在程序里面加一些默认的特殊业务逻辑，比如：用 null 表示不可用，size 等于 0 表示黑名单，这就是一个雷，下一个修改者，包括自己，都不会记得有这样的约定。对于这个例子，一个原则就是永远不要区分 null 引用和 empty 值。

*  **每行代码的可靠性与不可靠性的编码意识**

1.  培养这样的一个意识，根据编码经验，理解哪些操作最大可能存在不可靠性。
2.  rpc调用可能存在调用失败情况。更新数据库数据存在程序失败情况。跟缓存层交互过程中也可能存在失败情况。
3.  并发容器ConcurrentHashMap默认是线程安全的，这样可以理解为有可靠性的。
4.  失败后应该怎么恢复，容错。编码应该提高清晰的切入点。  
    结论：**可靠与不可靠完全独立开。提供清晰的切入点。考虑到容错。恢复**。

*  **参数状态合理性的编码意识**

1.  应该尽早检验参数是否合理。一旦，不合理则立即抛出异常。异常不是错误，是当前的数据信息不满足业务需求，因此，应该大胆抛出异常即可。

*  **空指针编码意识**

1.  去数据库查询了一条数据，返回的null还是非null的size？这些都需要有潜意识理解。
2.  从任何一个方法返回一个实体，都应该考虑到是否：null，甚至可以这样做，不用阅读原来的方法是返回怎样的实体。在调用方，如果要调用这个方法，则自己应该做到判断而不是依赖原来方法实现逻辑。因为原来的方法逻辑可能是会修改的。

*  **List的size是否越界编码意识**

1.  拿到任何一个List应该考虑list是null吗？又抑或size是0呢？
2.  或者size不是0呢？在根据size的大小写业务逻辑过程中，不应该依据具体的业务写方法，比如此业务逻辑告诉我，size的大小一定是3,就按照3写具体的业务逻辑过程。而应该反过来思考，我的方法仅仅是完成某件事的媒介，永远不要跟具体的业务逻辑过程耦合起来。

*  **不要吃掉异常的编码意识**

1.  异常不是错误。有了异常，能够处理就处理。不能处理则抛出即可。
2.  在代码中，进行必要的数据信息检查，一旦，发现检查的数据不合理了，抛出异常即可。如果要捕获到异常，则捕获到了，一定要处理，不能吃掉了。否则，很难排查错误信息。

*  **横向编码操作细节编码意识**

1.  横向编码，是相对纵向编码而言。横向编码其实并不知道别人做了一件什么事，以及是怎样做的。
2.  横向编码细节：入参一定要记录日志。这样可以准确定位问题。一来是知道是否调用了自己写的方法，二来是知道别人传递过来的参数是什么。

#### 小结 ####

*  记录一些核心的非常重要的编码意识规范。如果能够做到，编写的代码就会很好，结构清晰，易懂，像散文诗。
 *  培养这样的一个个编码意识，编码的时候，多想一下，写着写着，这些意识就有了，就成了自己的，谁也拿不走。真的。