工作心得之二 业务

   说到业务是个让人又爱又恨的东西，客户、领导把它看的很重，不少“技术控”却瞧不起它，认为它是“低智商”的代名词。当然了，这些看法都很偏激。技术仅仅是一个工具，因“业务”的需求而诞生至使用，小说里常常写到，当一个人学会了屠龙之术，却发现天地之间没有龙给他“屠”，这个是最悲惨的事情了，这里的“龙”就是业务，“屠龙之术”就是技术，离开了业务的技术是没有意义的。

   业务本身是个抽象的集合，真正把它搞懂了其实也能锻炼人的抽象能力。

   说来说去“业务”是个什么东西，似乎没有明确的定义，我觉得“业务”就是个“标准”，程序员完成的系统必须满足这个“标准”，不同行业，不同硬件环境都会有自己的合适的标准，某项技术都有其对应的“标准”。

   比如一直讨论很久的问题，C++和Java到底谁快，为此也有衍生出了很多讨论，技术控也是乐此不疲，但是或多或少都脱离具体环境。

   计算机语言发展了这么多年，都会相互学习优点，不过总有些本质的区别，比如C++的优势是和硬件结合紧密，Java的优势是屏蔽了硬件限制，两者在诞生的时候发展的方向就有不同，比如通信系统的交换机等各类硬件的程序非C/C++莫属，Java在这里难有使用的地方，但是在异构硬件集群中，现在很火的“云”系统，Java的优势就很明显，现在常用的服务器系统大多都是Java。当然也有人说Java免费，所以比C++更容易推广，的确没错，但是这也属于“业务”的范畴。

   说完了业务的大范围，下面说说具体行业的业务。我最熟悉的是电信的业务。相比金融、电商系统，从网上的信息来看似乎电信的系统是最没技术含量的，其实电信的数据量远大于金融、电商，只是大量的数据是后台处理，可以异步展现，所以给的要求并不高，总体来说电信系统是入门的技术低，做好了很不容易。

   我和不少电信的程序员人聊过，他们纷纷吐槽是，工作就是配置各种业务参数，体力活。但是说到具体的业务模型时，却说不清楚。

   我总结的电信系统分2两大部分，业务模型（CRM）和工作流（IOM）。CRM和IOM是比较老的名词了，新的我也不太清楚。

   模型如下：

   主产品+子产品+产品规则+动作

   解释如下：

   主产品，和硬件挂钩。现在的电信产品有手机（移动，联通，电信分属不同网段）、固话、ADSL、光纤、2B+D、30B+D等。

   子产品，依赖于主产品。比如移动电话的各种优惠包，宽带的互联星空等。

   产品规则，这里是最让人抓狂的。产品规则分3类、

   1、主产品规则，主产品之间是没有任何关系的，比如一家人可以装两条宽带，用多个手机。

   2、子产品规则，基于不同主产品的子产品之间没有任何关系，基于同一主产品的子产品之间有各种规则，比如手机的资费包开通了一个就不能开通另一个，这类为互斥。不同的优惠可以共同作用，这类为叠加。由于各种子产品的数量繁多，所以这些规则的校验和实现是个很庞大的数字。

   3、运营商制定的规则，比如，从硬件角度来说，装宽带、装电话、开通手机是互不相干的，但是运营商制定了各种套餐，“强迫”统一办理。这个无论是对程序员还是消费者都是是很讨厌的……

   动作，装、拆，（改=装+拆）

   分析完了以后可以发现真正麻烦的地方是业务规则这块，一个电信客户系统的质量高低很大程度上就由这个“业务规则引擎”决定，如果只是闷头往这个引擎里加参数的确无聊，但是这正了解这个引擎的工作步骤还是很有趣的，个人认为理解一个系统的运行是很容易提高能力的。

   下面说说“工作流”，消费者的任何一个请求在电信系统中都会转变一个流程，某些特殊的业务流程会很长，比如装高清宽带，需要人上门施工，并测试宽带质量等，这些都成功了才会触发其它的步骤。消费者的业务请求在后端实现往往是“事务”型的，比如原来是套餐A，改成套餐B的会有3个步骤，不熟悉电信业务的人可以想下“神州行”改“全球通”。当步骤1和2施工成功后，步骤3发现现有条件不满足时（这里的判断不在当前系统中，或者说当前系统无法判断，必须将数据发送到另一个平台之后由那个平台来判断，这种情况在电信系统里很常见，比如当前系统没有客户资料，所以无法判断），也就意味着不能办理套餐B，这样得回复成套餐A，这样需要对步骤1和2得进行反向施工，也就是“事务回滚”。先后这就是“工作流”的任务。

   工作流在电信系统中是很重要的角色，相比于是电商和金融系统，电信系统的工作流最强大。

   简单解释下工作流，工作流有两个最基本单元(节点)，逻辑节点和工作节点(不同的系统中叫法也不同，但是作用都一样)。

   逻辑节点，就是if判断。

   工作节点，就是一个具体的施工环节，一般关联一个平台。

   一般工作流的具体配置都由这两种节点组成。

   工作流定义的关系有，串行和并行(电信里的叫法是同进同退，一般直接定义成事务)。  

   于一个系统来说，业务层的调优效果优于代码层的调优效果(代码错误引起的宕机问题不属于调优范围)。比如，一个业务的判断规则精简了，比你优化几个计算语句强的多。比如之前说的例子，在步骤1、2、3中，因为3出了问题，导致1、2得反向施工，所以实际有5步操作，1、2、3、2反向、1反向。所以如果3最容易出问题，那么应该调整顺序应该是3、1、2，把最容易出问题的放在最开始，这样可以避免不必要的步骤。其实在系统上线后运行一段时间，就可以统计出那些平台的出错率高，调整顺序几乎是0修改，但是带来的效率提升是明显的，但是没有几个地方有这么做的。

   说了这么多，我觉得把整个系统的框架搞明白还是很能提高个人能力，抽象逻辑对于程序员来说必不可少。所以现在每次抱怨工作无聊时，我都会想想，真的就不能挖出点东西么？