Blame Oriented Programming

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

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

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

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

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

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

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

Comments

comments powered by Disqus