Blame Oriented Programming

面向对象编程大家都知道，之前还听过面向“离职”的编程，意思就是写代码的时候要假设自己马上要离职了，考虑的接手同事的感受，应该把代码写的简单明了，多做注释，多写文档。今天给大家介绍“面向锅的编程思维”。

作为后台开发人员，自己的后台服务通常都会调用其他人的模块。在系统设计的时候，面临服务之间调用的异常，有两种做法。

  1. 根本不考虑异常情况，调用失败也不处理。假装所有接口都一定会成功。
  2. 考虑异常，但是觉得服务是对方的，挂了的话责任应该是对方的。所以只做简单的重试。

第一种做法必然不可取，一般也只有刚工作的程序员才会如此奔放。大多数人可能选择第二种做法，但是服务上线有问题后很可能锅就落到自己头上了。为什么？因为对老板来说，他并不关心具体原因，只知道这个功能有问题，你俩都要挨板子。这个时候很可能就说不清楚了。比如对方说，我的服务就是需要由调用方保证成功的，或者说我的服务不保证100%的成功率，如果你要求100%那就不应该用我的服务。这样一来，主要责任反而会落到自己头上。

那应该怎么做？对于每个可能失败的地方，都要做好以下思考。

  1. 可能失败的地方是否关键路径，失败了影响大不大？会不会影响升职加薪？
  2. 能否进行重试，如何进行重试？特别需要明确的是，重试的考虑，是有可能超过主流程的工作量的，因此这也是评估整体工作量的非常重要的一个因素。
  3. 如果重试不成功，那应该如何处理？如果最终没有解决方案，那至关重要的一点是让各方都知晓此处存在的风险，由整个团队来进行评估，不要自己一个人做决定。

这些其实是我自己的痛点。一开始没有考虑好，最终要花费很长的时间去修复这种问题。更别提这些问题已经造成的后果了。如果早一点意识到这些，那该多好。