关于架构师

   一个架构师需要具备什么样的能力呢？

    听着架构师这个词，很神圣很吓人的。盖茨，世界首富。微软，世界上最大最富有的软件公司。盖茨是微软的首席架构师。好多程序员流口水，一听首席架构师，就两眼放光，貌似架构师的头衔比技术总监的头衔还厉害。

    一想起架构师，大家就想起了那些UML设计工具，类图、时序图，想起了那些水泥大楼的框架和地基，想起了那些如百变金刚的开发平台，想起了哪些让人眩目的反射、元数据、Framework、设计模式、面向对象、重构。

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

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

     1、掌握核心软件技术。要攻克数据库设计问题，必须深入了解数据库的工作原理，而不是会写复杂的SQL，会管理个备份设计个表结构就算精通数据库。有人甚至把会用hibernate、struts、spring当做自己会核心软件技术。

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

    3、了解软件趋势。

          在企业管理软件开发领域，往往会见到这样的现象：不少开发人员精通客户需求，深入第一线做客户实施。他们学习技术也是为了解决现有手头问题。尤其在企业管理软件开发领域，技术要求并不高，如果不了解客户需求，开发的软件实用性就不强，即使你功能开发的性能好、安全性高，也没有实际意义。所以，不少在企业管理软件开发领域工作多年的开发人员，形成了技术轻视观，甚至有种核心技术学习无用论的思想。但在企业管理软件开发领域，经过十多年的发展，已经面临了不少挑战。但是很多人觉得那是大环境的事情，大环境不是一个公司一个人能改变影响的。大环境变，咱们就变。大环境不变，咱们就照旧。但是，我已经经历过了很多时代，见证了很多遗憾，大环境发生了变化，自己却跟不上了。DOS\Windows时代、单机\局域网时代，互联网时代、移动增值时代。每一个时代都出了黑马，赚取的金钱突然高出传统数倍，而传统模式者还是在继续走传统模式，辛苦地赚钱，而且随着价格战的加剧，越来越辛苦，但还不思改变，并且还认为不可改变者大有人在。

    4、具备创新技巧

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

 

------------------------------------------------------------------------------------------

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

我们做架构，不就是为了达到这个目的嘛。如果我们用某某框架+某某框架，认为自己做的是最成熟的架构，但真正开发业务应用的时候发现开发起来很困难，不顺手，不易用，学习曲线高，跟踪调试成本高，维护成本高，那这样的框架我们就不要用。看上去好看却不实用的东西，不是我们程序员该做的。

很多人问我怎么研发一套可扩展的架构。我说，你不了解这个架构最后的演化未来，不了解这个架构的生命周期，那么你就无法研发可扩展的架构。我们是做企业管理软件的，不是做一个百变金刚的企业业务开发平台。架构所应用产品，它的生命周期是3年，5年，还是10年，20年，决定了架构的要求。