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

背景

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. 横向编码细节：入参一定要记录日志。这样可以准确定位问题。一来是知道是否调用了自己写的方法，二来是知道别人传递过来的参数是什么。

小结

• 记录一些核心的非常重要的编码意识规范。如果能够做到，编写的代码就会很好，结构清晰，易懂，像散文诗。

• 培养这样的一个个编码意识，编码的时候，多想一下，写着写着，这些意识就有了，就成了自己的，谁也拿不走。真的。