近两年公司采用SOA架构为原来的产品做了一个新的酒瓶子，主打分层解耦、套件化，并且上马了流行的分布式框架。高大上的新瓶子起初看上去美丽如蝴蝶，让人看到了整个BG登顶未来的巨大前景。但在落地的时候，整个组织从上到下都感受到了持续的阵痛。
知识密集型流水线
一套复杂的业务系统，通常会有着复杂的服务编排。以单个复杂业务为例，服务编排从打开某个页面就已经开始，接着是复杂且长的订单流程（工作流）、扩展实现以及微流程，从UI到持久层，串联着两条线：服务总线和工作流，简称程序工作者的流水线。
接下来是重点，流水线长且宽，会出现哪些壮观的景象呢？
螺丝钉的苦你不懂
在大型SOA架构里面，程序猿是苦逼的。在一个不成熟的大型SOA架构里面，程序猿的工作更是煎熬。
苦一：SOA架构的核心特点之一是要有明确的接口定义，如果没有准确的文档可查，或者已有文档但是极不稳定经常更改没有基线，那么不幸的程序猿无论是作为接口的调用方还是被调用方，只能一脸懵逼。
苦二：套件化是商业化的产物，为的是独立的功能可以单独售卖，可这也能坑苦了我们的程序猿。归属不同套件的程序猿顺理成章地只懂得单个套件内的业务，也只维护归属套件的代码。前面说了，在没有良好的接口定义的情况下，套件之间的联调就是一场噩梦：几乎找不到一个对整个业务端到端理解透彻的人，而且当要阅读其它套件代码时通常要通过网络电话找人口述或者远程桌面“观赏”。程序猿一旦失去了对代码的控制，犹如男人失去性能力。
苦三：还是套件化之后的联调，要知道，一条长且复杂的精密的流水线，是承受不起流水线停滞带来的灾难的。但是，在一个不成熟的套件间联调过程中，这样的灾难频繁发生。可能某个很委屈的童鞋提交了一个BUG或者代码、脚本漏提、错提，或者服务器、数据库故障等，悲剧就发生了：一个版本内几十号程序猿同胞们都只能静静地等待，运气好个把小时，运气差一两天就过去了。你尽可以发挥你的想象力，想象一下悲剧接连发生的情景。
你苦，因为你是螺丝钉嘛，不苦你苦谁？
专业性很强的流水作业
导致这些问题的系统以及管理层面的原因暂不做讨论。我们来看看流水线的程序猿在做些什么。
其实很简单，不外乎拿到上游的输入，处理之后输出给下游。某些专一的程序猿们专注于处理自己责任模块内的事务，对上游做了什么下游要做什么充耳不闻。这是在大公司的业务开发人员在做“流水性作业”的常态。但这显然不是正确的专业人员应该有的姿态。
这是程序猿的自贱。
只专注责任模块，坏处是很明显的：
- 不懂上下游业务，也就是没有探究需求的全貌，也就是没有明白客户需求，在出现业务问题的时候需要拉通上下游去解决，费时费力，而且可能在需求盲点上留下BUG。
- 只专注责任模块的代码，长此以往不利于技能的更新和进步。不同模块的代码设计、实现是不一样的，掌握更多模块甚至整个系统（这一点不现实啊）总是可以让程序猿受益匪浅。
写代码毕竟是一项专业性很强的技术工作，它是严谨的工程，严谨的工程需要严谨的对待。一个严谨的程序猿才配得上工程师的称号。
程序猿如果抱残守缺地只想把自家门前雪扫清，那么在大公司被视为低端工种也是理所应当了。
程序猿的初心
做一个优秀的程序猿，研发出厉害的技术，开发出牛逼的产品，同时拿着让人羡慕的高薪——也许只有最后一点还算勉强实现吧。现实是，大量程序猿们淹没在重复地所谓的智力型工作里面。
这是现实，尤其是在大公司内从事业务开发的可怜的程序猿们。但做好以下几点，我们依然可以有所作为，现实也可以变得美好许多：
- 首先，打铁还需自身硬，尽量掌握工作所需的专业技能。编程语言的基础掌握得足够牢靠吗？懂得性能调优吗？掌握了所使用技术、框架的原理了吗？这些是硬能力，是工作所需，也可能是立身之本。
- 其次，会写清晰的技术文档，擅于组织培训学习，乐于分享、沟通，都是重要的能力、特质，而且是可以通过训练习得和自我培养的。这些能力、特质可能不是必须，却可能是你的转身之本。
- 再次，在系统地构筑了自己的专业能力之后，还要保持自己的专业态度和独立的技术主张。因为，在大型组织内部，可能会经常存在多头指挥或者受到外行人士的忽悠。所以，建立和保持自己的专业自信，无论对工作还是做人都是珍贵的。
- 最后，知其然，知其所以然。这一点非常重要。程序工作本身是讲逻辑、因果的，这是程序猿的优势。程序猿应该借助这样的思维优势，小到一段代码、大一点到一个端到端的业务、再大一点到某个架构设计、再辐射到整个系统架构、再到团队和流程建设、再到行业发展...都试图去理解因果，看到表象背后的逻辑和本质结构，坚持下去，时间会把礼物一个个送到你的身边。
