工作心得

最新推荐文章于 2025-09-12 18:08:49 发布

最新推荐文章于 2025-09-12 18:08:49 发布 · 73 阅读

文章标签：

#java #设计模式 #面试

转http://wupuyuan.iteye.com/blog/1381437

工作心得之二业务

博客分类：
经历总结

业务电信 JAVA 工作流

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

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

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

比如一直讨论很久的问题，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修改，但是带来的效率提升是明显的，但是没有几个地方有这么做的。

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

工作心得之三-技术

博客分类：
经历总结

最近离职交接的差不多，前段时间的总结还差最后一篇，技术。 这里我不想讨论具体的细节，一方面，我算不上高手，另一方面也不是几百字能总结的了。仅仅总结自己的心得。 记得刚刚工作那会理直气壮的自称“精通”，那时无非是上网的面试题都做了一遍，面试时脸皮厚了一点，所以自我感觉还不错。不过现实工作中的实际问题确确实实的压着我，过了两年只能厚着脸皮说精通，现在想想勉强还算是“精通”吧。 对于“精通”的定义网上有很多说法，没个统一，我只说说我的看法。 先说说写代码，这是每个码农必备的技能。写代码我是划分为4层 1、能运行 2、能运行，简洁 3、能运行，简洁，高效 4、能运行，简洁，高效，易读 解释下： 1、第一阶段是按照要求能把程序完成，没有太多异常。不过这个阶段大多都是照猫画虎，模仿别人的程序来写。这时最明显的特点就是一个方法中完成N多逻辑，每个方法都很冗长。 2、第二阶段可以独立完成代码，不需要“过多”参考他人代码，有自己的编码风格，命名规范。相比第一阶段会省略很多不必要的语句。开始“背”一些设计模式，掌握基本算法。 3、第三阶段属于精通了，有针对性的调优代码，对于程序的逻辑控制，语法优劣都有明确的认识。对于设计模式有自己的理解，也掌握不少算法。 4、第四阶段算是老鸟，往往开始转为架构或者转为管理，基本功都已经扎实。他们写的代码特点是清晰明了，可以很明确的区分不同的包，不同的类，和不同的方法。 提升自身能力的方法有很多，我总结如下： 1、兴趣，如果误入这行，尽早转管理或者设计吧。 2、多读代码，现在开源的代码相当多，JDK本身代码就足够学习，这是最基本的方法。 3、设计模式，虽然对这点争议很多，但是不可否认，真正理解它的时候，会很有用。 4、读书，堪称经典的书籍有很多，认真的读两本就够了，一般来说没时间让你读个遍，另一方面，一本吃透了可以触类旁通。 5、相互印证，这是我一个朋友说的，他不是JAVA方向，是稍微偏门的语言，他的经验是多学学别的语法，可以相互比较。他现在会N多语言，有多精通说不清楚，不过他可以经常用某个语言的优势来解决问题。 6、要是身边有个高人，就事事缠着他吧，F2F永远是最有效的手段。 想来想去，能写的也就这么多，希望以后几年有更多的吧。