软件架构师：走钢索的人

架构师是个很神圣的词。盖茨，世界首富。微软 ，世界最大最富有的软件公司。盖茨是微软的首席架构 师。

      好多程序员 流口水 ，一听某人是架构师，就两眼发亮，比技术总监的头衔还要厉害。

      一想起架构师，大家就想起那些UML设计工具、类图、时序图，想起那些水泥大楼的框架和地基，想起了那些

      如百变金刚的开发平台，想起了那些让人眩目的反射、元数据、FrameWork、设计 模式、面向对象、重构。

     很多人想当架构师，感觉架构师是技术职业发展的最高境界，在往上走就有管理 职能了，如技术总监和CTO或研发总裁之类的头衔。

     李维先生曾经有过一次演讲，讲到了一个架构师应该具备的特性：

      1核心软件技术。要攻克数据库 设计问题，必须深入了解数据库的工作原理，而不是会写复杂的SQL 会管理个

     备份 会设计个表结构就算精通数据库。有人甚至把会用hibernate\structs\spring当作自己会核心软件技术。

      2产品特性。你学了那么多核心技术，到底要干吗？我一直在商业软件公司工作，没有在研究所工作过。我各种技术要做到的就是帮助企业软件生产，如何更快更省力气质量更好市场竞争力更强。我总是以这个原则来验证一项技术是否对于我的工作来说而实用。现在技术多如牛毛，在各个层次各个领域解决着各个环节的问题。如果不以解决自己工作中的问题为圆心，很容易陷于到大量学习 却越来越茫然找不到出路的境地。

      3软件趋势。在企业管理软件开发领域，往往会见到这样的现象：不少开发人员精通客户业务需求，深入第一线做客户实施。他们学习技术也是为了解决现有手头的问题。尤其企业管理软件开发领域，技术要求并不高，而如果不了解客户需求，开发的软件实用性就不强，即使你的功能开发的又性能好又安全性好也没实用意义。所以，不少在企业管理软件开发领域工作多年的开发人员，形成了技术轻视观，甚至有种核心技术学习无用论的思想。但企业管理软件开发领域，经过十多年的发展，已经面临了不少挑战。但是很多人觉得那是大环境的事情，大环境不是一个人一个公司能改变能影响的。大环境变，咱们就跟着变。大环境不变，咱也照旧。但是，我已经经历过了很多时代，见证了很多遗憾，大环境发生改变了，自己却跟不上了。

     DOS\WINDOWS时代、单机\局域网时代、互联网时代、移动增值时代。每一个时代都出了黑马，赚取的金钱突然高出传统模式数倍，而传统模式者还是在继续走传统模式，辛苦的赚钱，而且随着价格战的加剧，越来越辛苦，但还不思改变者并且还认为不可改变者大有人在。

     4创新技巧。我们往往会遇到这样的情况：要解决手头的问题，摆在面前的有N种技术方案。选择哪个都有缺点，综合来用又感觉牛刀杀鸡了。有时候，我们还会遇到另一种技术选择，未来的软件趋势一定是那样那样的，但现在还没有达到，现在的技术方案都是过渡期的，所以我们还要等。否则利用现在的过渡期技术，开发出来就被淘汰了。如果是这种以现状看技术的思路，不管技术发展到什么阶段，都有遗憾，都在向未来的未来过渡。所以，作为一个架构师，比别人厉害就厉害在，总是能把手里这些技术巧妙的利用，以解决自己的问题。当然，你想把你手中的技术能用活，你必然是理解这项技术的来龙去脉和这项技术的适用领域，还要深入理解这项技术的工作原理，还要清楚的认识到你要解决的问题领域，否则，你无法把你的技术和你要解决的问题结合在一起。

      我对李维先生的这四点讲述颇为赞许。架构师总是游走在技术和业务之间，既要兼容软件历史不能割裂又要面向未来发展，所以我老把架构师称为走钢索的人。

      很多人也想成为具有这样特性的架构师，但就是不知道该怎么走这条路。我就讲讲我的经历。

     我刚出道的时候，很快成为公司技术出众的程序员。有人跟踪调试了一下午也找不到错误的，找我；有人不知道这个错误是怎么引起的，找我；有人不知道某个需求怎么实现代码方便，找我；有人要优化数据库性能，但怎么都速度提不上去，找我；有人要修改一段超复杂的代码，怎么也理不出来，N多判断和函数嵌套，脑袋思考不过来了，对代码的复杂度掌控不了了，找我；我就跟一个活雷锋一样，大家也好像觉得我就是个活字典，有技术问题找我总没有错。就这样，我在研发部有了很好的技术信任，也有了很好的人缘。

     而架构师要做的工作，是许多人工作的基础。如果没有很好的技术信任，大家怎么敢把他们的工作搭建在你的基础之上。如果没有很好的人缘，大家怎么愿意把他们的工作搭建在你的基础之上。就是由于我解决了很多业务开发的问题，我了解了很多业务开发的现实状况，并且还能提出简洁有效的解决方法，而且解决方法不死板不铁板一块能保持独立灵活通用性，给其他人的工作带来了很好的工作效率，所以领导才信任我能做好这一块，并且适合做这一职位。不是随随便便一个人深刻学习了核心技术，然后申请领导要当架构师。

      其实，我开始做的也仅仅是公共代码员。但是，很快面临了一个尴尬。

      简单的，虽然可能每个开发组都重复写同样类似的代码，但是由于简单，所以每个业务开发组都自己写了。

     复杂的，往往业务开发组组长都认为这个功能是自己这个组的个性功能，所以还是自己写。

     所以，只有人们解决不了来找我时，我才能上场。

     这干坐着不是回事。我得自己想辙。

      于是，我在忙“公益事务”做活雷锋之余，看到他们在扎堆开会我就主动去旁听。每次我都能提出很独到的见解。并且能帮助他们写公共抽象代码，能帮助他们提高不少工作效率。所以他们非常愿意让我旁听，并且听取我的意见。我也能很快写完让他们用。他们一用，发现果然好用，而且不用他们自己写代码了，功能实现的还非常巧妙公用，性能也好稳定性也好扩展性也好。到后来，每次开会都主动叫我。这样，我的工作就越来越多了。

     随着各个业务组不同差异的需求都希望我来帮他们抽象出公共的，我就在思考我手里的这部分代码。我不能今天他们提一个我写一个。他们倒是轻松了，但我手里就好似一盘散沙一样。于是，我不断重构我的公共代码，架构体系框架就这样慢慢成型了。各种各样公共工具，调试工具、优化工具、动态设计工具，凡是能帮助业务开发组人员加快效率的，我都做了工具或写了公共函数DLL。尽量简单易用，不让他们觉得麻烦或不顺手。

      过去，各个业务开发组过去是开发人员素质不齐，有人责任心强，有人随意；有人细心，有人粗心；有人理解客户业务深刻，有人理解不深刻。所以开发出来的质量良莠不齐。自从这样做了以后，各个组写的代码少，很多都是我写的公共代码。我的技术好，写的代码质量高，而且是公共的，有错误，一改，大家都没有问题了。所以我们整体的软件产品的产品质量、生产速度都提高了不少。

      我发现，大家越找我，各种需求交织在一起，越复杂，我就越需要更深入的学习技术，深刻理解各种技术的差异性和适用领域，去思考各项技术的发展历史、未来趋势，并且自己做DEMO，看能不能更好的解决大家的问题。因此，我的技术能力也越来越高。如果我不去解决这些不去第一线想也想不到的客户需求，我根本就想像不出我某项技术还能这样用。

     这就是我的螺旋上升之路。

     我那天重翻上个月的《程序员》杂志，看到了我朋友周爱民写的一篇《做人、做事、做架构师-架构师能力模型解析》，他也提到四点，技术能力、业务能力、人际关系、个人内在素质。和我的情况很类似。

      有一部分所谓的架构师，技术超深厚，框架堪比Spring之类，但自己一个人闷头写框架不断优化，力竭使用最先进的技术思想，希望把最豪华的设计模式融进去，希望把OSGi融进去，希望把AOP融进去，全无视那些想利用框架减轻自己工作量提高自己工作效率的应用功能开发同事。这是在用公司工资玩技术呢，还是在满足个人技术幻想呢，还是在实验呢？到底在干吗？价值在哪里？

      还有的人不会推广自己的框架。不善言辞，就幻想着技术总监能够通过行政命令让大家必须用框架，能不自己写代码就不自己写代码，能交给框架做的就交给框架做。但技术总监号召完了，大家仍然我行我素，各自开发为政，让框架开发者很孤单。

     还有的人也不会推广自己的框架，沉迷在自己的理想世界。好不容易技术总监召集大家让大家来听听框架如何应用，但自说自话，满口自己最得意的词汇，听得业务功能开发人云山雾罩。大家问些问题，如这样的业务开发难题，框架怎么解决？于是，框架开发员就和业务开发员争论了起来。框架开发员觉得这根本就不能答应客户这种变态的需求，而业务开发员说这就是现状。框架开发员说你可以这样这样，业务开发员说这样太麻烦，框架开发员立刻还口这还麻烦？于是双方各执一词，框架也没推广成功。

      我手底下有个框架开发员。他的技术渴望很强烈，为了技术难题攻克，可以不吃不睡。并且技术敏感度很强，学习也快。所以当时我感觉他是个程序员的料，就把他拉到我的手下。

      但是有个问题，他写出的框架代码，在平时开发业务功能的时候挺麻烦。大家可能需要的是一把铁锹，但是他却给大家N根不同长度不同粗细不同材质的木棍，N个不同形状不同用途的铁锹头。大家会有N种组合。不仅导致他写代码老超任务期，而且也让使用人感觉没多大帮助。使用起来复杂，而且还得配置这个配置哪个，需要注意的地方太多。业务开发组的同事就不愿意用，还不如把代码自己直接写死了得了。超期还会影响业务功能开发组的使用。本来人家是为了想加快自己的工作效率。你答应好这个星期给业务开发组提供一个功能，但你没有拿出来。就耽误人家进度。你多次拿不出来，人家业务开发组还不如自己开发一个呢，求人不如求己。

      我最后警告他：如果你认为自己技术够牛，那么你必须证明你能很快做出来。如果你认为自己技术够牛，最好能牛到，只提供一个函数就解决了他们的问题。别这个代理类，那个聚合类，这个唯一实例类。最好连参数也没有，大家调用一下写一句代码就OK。甚至你做的好，大家都不用调用你的代码，你可以包含在基础框架中，你自己去判断什么时候什么应用需要执行这个动作。如果你认为自己技术够牛，那么在业务功能需求发生变化的时候，你能够保证接口不变的情况下还能适合变化，这才你够牛。别让业务开发组的人跟着你也得改他们自己的代码，那样的设计就很烂了。

      小伙听了我的话。进度保证，代码接口简洁。

      他说，你真高。我感觉现在我的技术比过去进展飞快。看来人不逼，是不会自己创新更好更快的方法的，老认为自己现有的方法已经不能优化了。我现在发现，很多我过去写的东西还可以做的更好，我准备在开发任务之余优化代码，但肯定保证不影响大家，接口还跟过去一样，我要重构一下。

      我对小伙的成长感到欣慰。

      但是，小伙还有一个没有逾越的鸿沟。这个问题不解决，我知道，他不会成为一个真正的独立的架构师。

      我复查过他的代码，由于他对业务没有深刻理解，所以考虑了N多种情况，给自己以后的修改留下了后路。但也因此代码量大，开发周期长无法适应越来越短的客户需求响应时间，可阅读性不强，功能复杂，稳定性困难。但我从客户行业出发，很多情况他其实都是自己假想的，而且想错了。

      我指出了他的问题。他问我该怎么学习业务，他又没有机会到客户一线去实施，也不接听客户电话，客户需求都是业务开发组的人跟他说的。

      最了解客户业务的，是在一线做客户咨询、做客户实施的人员。其次是做客户定制化、客户服务支持的人员。最不了解客户的，就是架构组的人员。但恰恰要命的是，架构组的人员做的功能是大家的工作基础，如果基础设计错误，那传递的“牛鞭效应”破坏力就很大。所以，架构必须了解业务。

      我了解业务的思路，和我了解技术是一个思路，都是来龙去脉法，研究一项事情的过去、现在、未来，以及和这件事情关联的其他事情，研究方法也如法炮制。

      你要制造的是卡车还是轿车，你得明确好。你是要造100万的轿车，还是5万块钱的轿车，也得定好。你是要制造一辆可以自由改装的轿车呢，还是一辆只可以大致改装一些的轿车的，也得定好。这些疑问，都是和咱们面临的客户有关。而我们能面临什么层次的客户，和咱们公司的实力、品牌、组织规模、盈利要求有关。

      你如果是一个小公司，想做百万大单只能做的一蹋糊涂。你如果是个大公司，你老去竞争那些5万块的小单，做一个赔一个。所以一个公司的出身就决定了它的竞争地位和它的目标群。我们要为这个目标群服务，所以我们就不要做一个百变金刚的架构。公司有公司的目标，公司招了你给你付工资，就是为了让你为目标客户群服务。如何更快更好更有质量的服务，就是公司的目标。我们就是为了帮助公司实现这个目标。

      我一般都是把我们这个产业的竞争格局现状了解清楚，我们的过去现在，竞争对手的过去现在都了解清楚。然后我去研究我们的客户行业的竞争格局、层次现状。看看这个客户行业盘子，三教九流到底多大多复杂，

      我们现在是占了多大，我们还能占领哪些客户群。

      然后我就研究客户行业目前的挑战、机遇、困境。能解决其中一两个问题，就是咱们的竞争亮点。如果作为软件一点都解决不了这些业务困境，我就思考如何让产品做的更易用。微软不就靠着易用发家的么？

     最后我会去研究我们公司现有的研发优势和弱势、实施服务销售的优势和弱势，找到适合我们突破的地方，具体归研发能承担能起作用的事情，我就会去动员做。脱离现实资源现实矛盾现实包袱的改良，是无法做到改良的。

      我还关心各种新的技术应用。可能这项技术很久了，但大家都没有想过还能这样用。所以，我常常在媒体上关注这些、思考这些、在论坛上和业界交流这些。对于新的技术，要研究原理，要尝试，但不要冲动引入到商品生产中。我们不是自己在创业在玩在实现自己的梦想。我们承担的是公司所有人都要吃饭的产品。如果有闪失，这么多人以及他们的家庭都要受到影响。这不是闹着玩。

      当我研究完业务领域的这些大的框框以后，每逢有业务同事跟我交流客户需求，我总能把这个需求和我的业务框架联系在一起，把这个需求归好类。并且能判断出这个需求是个反趋势的需求，还是个短期眼光的需求，还是个长远发展的需求。

      很多人都在抱怨说需求老变化。其实，不是客户需求在变，而是你对客户的需求老是不同思路去理解。我心中有业务框架，有过去，现在，未来，所以能识别出一个需求是稳定的还是临时拍脑门想出来的。有时候，有人向我提一个需求，我会眼睛一亮，对，这个需求符合未来发展，我就会很快加入。所以，我曾经在做实施经理的时候，老是能很容易说服客户，让客户听从我的意见，就是由于我想的比他们还要远还要周全。好多程序员说客户非要某个功能不做不行，就说明这个程序员并没有理解客户。客户并不是那个非要和你作对的人，他只想解决他的问题。可能你不理解他的真正根源问题而且你又提不出更好的方案，所以他要跟你急，要让你必须实现某个功能。

      只有你不断游走在业务过去现状未来与技术过去现状未来，你做的架构才是真正的实用、弹性、易用，而且最小成本，不走弯路，不多花开发精力。

     我们需要架构，不就是为了达到这个目的么。