业务模型的价值(程序员的另外一条出路)

最近一直忙于新公司的基础库建设和一些业务系统的开发，接触到了一些比较有思想的技术人员，在他们身上发觉到了很多值的深思的话题，也领悟到了一些比较有价值的经验在此与同行们分享一下也算是探讨一下吧；[王清培版权所有，转载请给出署名]

都说技术人员应该重视业务的学习和培养，只有精通业务了才能更好的发挥技术。其实我是不太赞成这句话的，为什么？从我的个人经历和经验来看，这是对的。当然世事无绝对，站在我们程序员的角度讲，我绝对建议技术人员始终要以技术为主业务为辅的观点。可能有些朋友要来火了，技术辅助业务应该是业务大于技术，凡事都是相对的。如果以业务为主，就等于把自己的小命送给公司管了，如果以技术为主那么小命还是自己保管的。这句话经历过的人才会懂，我就不解释了。

1：业务、技术如何平衡   

中国的行情我想我们都了解，对于一般的企业来说，技术不重要，重要的是能在最短的时间内出东西。80%的IT企业都是属于这种类型的，他们要求程序员快速的熟悉业务知识，然后就开始参与项目的开发。

大部分是重复劳动，程序员都在做些基本的增、删、改、查的工作。而且这些工作都是经过层层封装的，程序员接触到的技术面非常的窄。长期这样下去定力不足的程序员就会受到周围环境的影响。有的可能选择转行，有的可能选择做业务、做实施。其实这个时候我们应该勇于的选择，应该坚持自己的理想。当然这需要兴趣的支撑。

改行我就不发表看法了，毕竟人各有志。这篇文章讨论的主题是业务和技术的结合，如何在技术和业务之间提炼核心的领域模型，让我们的技术更有用武之地。

那么站在公司的角度讲我们应该多去学习业务知识，技术一般都是放在一些架构师手上，我们只要学会使用公司的框架就行了。

技术辅助于业务，搞业务的人始终觉得业务大于技术，技术人员应该听他们的。这种现象很普遍，至少我接触到的公司都是这样的。他们让程序员改什么就改什么，因为他们不懂程序的错综复杂，可能一点点的不合理都有可能造成程序的整体结构变动，带来的工作量可能是开发的几倍。领导又可能会说，你们能不能设计一个很模块化的，高内聚低耦合的插件系统或者又是什么新的名词。我们可能很无语，因为他们不懂技术？哪有一劳永逸的系统啊；

其实矛盾点就在于如果我们技术人员用大精力去学习业务知识，我们相对学习技术的时间会很少，那么我们就是把自己和公司绑在了一起。这个时候我们考虑的问题的角度是不同的，如果你重视业务那么你可能需要公司对你的提拔或者说是你的饭碗是捏在公司手上的，如果公司哪天看你不顺眼，你就失业了。如果我们的技术一直是领先的，那么我不怕你公司不要我，我到哪里都是能生活的。可能说这句话有点自私，但是我到觉得程序员应该学会保护自己。[王清培版权所有，转载请给出署名]

如果真的觉得你的领导值得你去追随，那么你就好好学习业务吧；如果公司真的没有值得你付出的地方，那请你好好学习技术吧；

2：程序员如何学习业务

我们程序员该如何学习业务？我觉得我们应该有选择的学习，不要所有东西都学。

一个公司的业务可能很简单也可能很复杂，我们要选择跟系统相关的业务，做哪块我们学习哪块，最重要的是有业务模型的概念在脑子里，这中模型化的思想可以看看《领域驱动设计》。

为什么要说有业务模型的概念呢？其实这是一种慢慢培养我们设计能力的方式。程序员学习业务知识在概念上一定要明确，不能模糊，因为这些概念都要在系统中体现的。如果我们理解上是模模糊糊的那么我们写的代码也是含糊不清的，在和同事交流的时候我们的模块可能造成其他模块的不明确，这时候瓶颈就来了。

我们学习业务知识一定要记得能否在代码中体现整体结构，能否提炼出业务模型；

图1:

我们学习业务知识要适当的归类，将某一条业务线上的对象抽象出来。

如果我们能善于在代码中表达业务，那么这和光使用技术来实现基本功能要强了很多。至少这是设计类的工作。(设计能力体现技术层次)

3：结合业务、技术提炼业务模型

在和一些搞领域模型的人聊天的时候，能感受到很强烈的模型感。他们对业务的理解很苛刻，不允许存在半点模糊。为什么要强调这么细致呢？这能使他们的模型更加健壮稳固。往往他们的竞争力非常的明显，精通业务和技术。

但是又与我们所见到的业务不同，他们能将业务顺利的过度到代码上。他们能将业务梳理的很工整，我们只要稍微了解一点业务就可以参与项目的开发，在代码中完全是按照业务的模型来构造的。这种人一旦熟悉了某个行业之后，是绝对的领域专家了。

总结：

其实上面废话一堆，也算是我最近来的一点小小的感悟吧。

技术是我们程序员的生命线，只有在技术上占据绝对的优势才能保住饭碗。然后将我们的技术提升到一个建模境界，那就真的技术服务于人了。谢谢；