锁定老帖子 主题:工作心得之二 业务
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2012-02-13
最后修改:2012-03-02
说到业务是个让人又爱又恨的东西,客户、领导把它看的很重,不少“技术控”却瞧不起它,认为它是“低智商”的代名词。当然了,这些看法都很偏激。技术仅仅是一个工具,因“业务”的需求而诞生至使用,小说里常常写到,当一个人学会了屠龙之术,却发现天地之间没有龙给他“屠”,这个是最悲惨的事情了,这里的“龙”就是业务,“屠龙之术”就是技术,离开了业务的技术是没有意义的。 业务本身是个抽象的集合,真正把它搞懂了其实也能锻炼人的抽象能力。 说来说去“业务”是个什么东西,似乎没有明确的定义,我觉得“业务”就是个“标准”,程序员完成的系统必须满足这个“标准”,不同行业,不同硬件环境都会有自己的合适的标准,某项技术都有其对应的“标准”。 比如一直讨论很久的问题,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修改,但是带来的效率提升是明显的,但是没有几个地方有这么做的。
说了这么多,我觉得把整个系统的框架搞明白还是很能提高个人能力,抽象逻辑对于程序员来说必不可少。所以现在每次抱怨工作无聊时,我都会想想,真的就不能挖出点东西么? 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2012-02-14
你在南京,又熟知电信业务,猜测LZ乃是亚联的。
|
|
返回顶楼 | |
发表时间:2012-02-14
cectsky 写道 你在南京,又熟知电信业务,猜测LZ乃是亚联的。
我之前从事电信行业,现在不是了,去年才辗转到南京。真不在亚联。呵呵 |
|
返回顶楼 | |
发表时间:2012-02-23
楼主,业务模型有些技术员说不出来是正常的!
在我的经验中,得有二个条件,第一是精通业务!这个业务是和业务人员理解的那种;第二是做过业务系统的架构与设计! |
|
返回顶楼 | |
发表时间:2012-02-23
我还真就是楼主所说的这种技术控。
不是说重视业务是低智商的表现 而是 技术不好,拿业务当借口的人,才真正是低智商的表现 |
|
返回顶楼 | |
发表时间:2012-02-23
zouruixin 写道 我还真就是楼主所说的这种技术控。
不是说重视业务是低智商的表现 而是 技术不好,拿业务当借口的人,才真正是低智商的表现 拿业务当借口的人!是有!但有些系统确实是业务更重要。我深有体会.......... |
|
返回顶楼 | |
发表时间:2012-02-23
amwiacel 写道 zouruixin 写道 我还真就是楼主所说的这种技术控。
不是说重视业务是低智商的表现 而是 技术不好,拿业务当借口的人,才真正是低智商的表现 拿业务当借口的人!是有!但有些系统确实是业务更重要。我深有体会.......... 貌似传统行业里都是业务更重要的。 ------------------------ 由于业务重要,很多人就耦合到所谓的业务里了,技术上不思进取,在公司熬个年头,混个项目经理,跳到甲方等等 当不上项目经理的,由于技术不行,哪也不敢跳,张着嘴等着公司涨钱,公司不给涨,也没办法不敢叫唤,只能没事多请客吃饭“表现表现”。造成了N多人都想当管理者,于是出现了这样的组织层次:应届生,小组长,副项目经理,项目经理,项目总监。。。 而除了应届生,其他人都是“领导”。 由于没人懂技术,“领导们”经常对应届生吹牛逼,我多么多么技术牛叉。。。 这样的公司有个好处 -- 团队非常的稳定 ------------------------ 懂的人自然知道,不懂的期盼自己别进入到这样的公司里去。 |
|
返回顶楼 | |
发表时间:2012-02-23
不懂业务,何来重构。
|
|
返回顶楼 | |
发表时间:2012-02-25
技术是为业务服务的,这个是事实,但是,每个业务也有自己的特色,并不一定说数据量大就一定技术含量高,数据量大1个月出结果,这也没啥技术含量吧。所以,数据量又有一定的返回时间限制才是技术体现价值的地方。如果google搜索要5分钟才返回结果,估计很多人都要骂娘了。所以说一个业务驱动的公司最后一定要向技术驱动转型,因为业务帮它开阔市场而技术帮它坚守阵地。(个人之言,请勿拍砖)
|
|
返回顶楼 | |
发表时间:2012-02-26
miroku 写道 技术是为业务服务的,这个是事实,但是,每个业务也有自己的特色,并不一定说数据量大就一定技术含量高,数据量大1个月出结果,这也没啥技术含量吧。所以,数据量又有一定的返回时间限制才是技术体现价值的地方。如果google搜索要5分钟才返回结果,估计很多人都要骂娘了。所以说一个业务驱动的公司最后一定要向技术驱动转型,因为业务帮它开阔市场而技术帮它坚守阵地。(个人之言,请勿拍砖)
业务帮它开阔市场而技术帮它坚守阵地 入行两年,比较认同这句,个人感觉理解业务比较快,技术上一般,不算牛,一直学习中 |
|
返回顶楼 | |