程序员应怎么实现转型架构师

        技术技能是架构师的必备条件。你需要有技术技能来获取这个职位，但是情商和理解组织业务的能力才定义了你有多优秀。

        程序员的理想？如果是选择技术这块，他们的理想都是架构师。这个问题在我们这个行业来说是很突出的，有的人理想做管理，有的人理想做技术。那么想做技术的这些开发人员来说，他们都很向往这种架构师的角色，应该说架构师也确实是站在技术这块是最高的级别。但是他们怎么成为架构师，在这个过程当中，他们应该做什么事情，应该怎么去往这个方向努力，其实他们都很茫然。事实上我们也知道，现在我们这个行业很多架构师，尤其是做技术的这些架构师，他们很多都是从开发人员这样一步一步走上来的。

        但是在这个过程当中，有的人就倒下了，有的人就一直就是成为一名普通的开发人员，或者软件工程师，没有走上这样一个层面。原因就在于，架构师需要的能力和开发人员需要的能力还是有区别的，我们要求架构师要有实现方面能力，这跟做建筑这块不一样，建筑方面可以直接培养一个架构师，但是就我们这个行业来说，从学院里面培养出来一个架构师是不大可能的，是需要有很多经验的积累，也是要有编码的这样一些技巧，这是必须的。就是架构师必须要了解实现，但是如果停留在实现这个层面，就不可能成为一名合格的架构师，是因为架构师把握的更多的是大局的东西，是一个更高层面的、抽象方面的知识。

        怎么才能成为一名架构师呢，需要在这方面有意识的培养自己，第一个培养，就是从行业这块，因为做我们这个软件行业，根据不同的领域，领域模型可能不一样，业务流程不一样，业务规则不一样。那么如果你对这个行业的业务规则、业务流程不清楚，你也很难得到一个好的理论模型，也就很难得到一个好的架构，所以从行业这方面，要有意识的培养这方面的能力。就是你可以集中在你公司所从事的一些行业，比如金融行业，或者制造行业，或者保险行业，电信、通讯这方面的行业，要有这方面的能力，你要有意识去积累。而不是要埋头光顾着写代码，而是有意识的去参与一些需求这块的理解和分析，这是我认为第一个。

        第二个，就是要去掌握一些提高自己的抽象能力，提高自己的建模能力。因为架构师所需要具备的最大的、最强的一个能力，就是能够从很纷繁复杂的需求当中，从很多细节实现当中，能够去抽象出一个共同的东西出来，能够从不同的地方，能够找到共同的地方，也就是所谓的共性和可变性这样一种分析，他们在这一方面的能力把握的非常好。然后这一方面的能力，把握抽象出来以后，还要把它形成为一个模型，形成出领域模型、分析模型、设计模型，通过这个模型的方式来把它表达出来，就是我认为要有意识的要积累这方面的能力。

        第三个，我认为应该有意识的、有前瞻性的去了解这方面的知识，不管是从网络上，包括像咱们InfoQ也有一个架构的专区，架构专区有很多很优秀的文章，都是国内外一流的架构师写的一些文章，可以有意识的去看这些方面的文章，或者是读一些优秀的书籍。那么从这方面来培养你在架构这一块的能力。

        第四个我觉得还有一个交流，有意识的提高交流，很多开发人员为什么没有在最后成为架构师，就是因为他们很多技术人员可能比较内向，偏向于研究，偏向于和机器打交道，而忽略了和人打交道。而架构师，我刚才也说了，架构师是在业务和实现的技术人员两者之间搭建一个桥梁，这桥梁一方面是从书面的角度、文档的角度来进行协作、交流，另外一方面就是口头方面来交流，而我们开发人员在这一方面还有所欠缺。所以我认为，开发人员要最后成长为一个架构师，第一个你要把目标定好，定好之后，就要有意识的往这个方向去发展，要培养架构师具备的这些能力。再根据多做一些项目，有效的、及时的去总结这些项目的经验，或者说及时的去学习一些，因为你可能是开发人员，但是在你的项目组里边，肯定有架构师类似这样的角色存在，那么你可以有意识的向这个架构师去学习，或者说从他那个地方得到的一些东西、方案，你学会去思索，去思考，这样我觉得慢慢的从经验上去积累，从技术上去积累，从能力上去提高，慢慢的我想，给你一个好的机会，一定能会成为一名合格的，乃至于优秀的架构师。

        困难应该还是抽象的能力和大局观的能力。因为我们要求开发人员的能力，就是要求他具体的实现能力，把握细节，某一个算法的一个实现，然后某一个业务流程，他怎么去实现，或者某一个技术，不管是什么语言，或者什么平台，某一个技术，比如说安全，或者是写一个Web Service，或者是写一个权限管理。在这一块来说，他们的能力是很强的，但是怎么把它提取到更高的抽象能力和大局观这块，我觉得很多开发人员都比较欠缺。

        首先从技术角度先说一下，对于架构师我的看法是首先要专，然后是博。就是第一个，必须得深入去了解你所擅长的某一个框架，某一个平台，一定要专。我说所谓的专，不是说把它每个细节都掌握得很清楚，而是要把它内在的原理搞得很清楚，这样即使碰到一个新的问题，你也可以能够很快的解决。因为架构师在基础这块，要树立起技术的权威，如果你设计出来的模型你自己都不清楚，我打个比方来说，你对通讯的协议都不清楚，你怎么去做架构设计，你怎么去把握它，所以必须得专。

        但是，还有一个很重要的就是要博，因为我们做架构、做软件，不一定是，一直做项目都会只用一个平台，只用一门技术，而且现在的项目，其实有一个发展，是多语言、多平台共存的这样一种发展，很多项目我们看到都有这种趋势。那么如果说你只懂一门技术，只钻一门框架，只钻一门平台，那么当需要你去集成多个系统的时候，你可能就束手无策了，所以一定要博。那么博的意思是说，由于软件，不管是什么平台，不管是什么框架，不管是什么语言，其实它的原理是相通的。由于你专了，所以你对它的语言、原理、平台的机制都很清楚，你要再去快速的掌握其他的技术，是非常容易的。但是又有区别，你需要去把握它不同的地方，同时你还可以取长补短，你可以用另外一个技术的优势来弥足你现在所用的技术的缺陷，所以这是我对技术方面的认为。

        而从业务来说，你要成为一位行业的专家，当然是最好，但是人的精力是有限的。一般来说我们有两种情况，一种情况就是如果这个架构师，他一直只做一个方向，就是他一直做汽车制造这块，那他可能随着经验的积累，慢慢慢慢的，他可能会成为一个汽车行业专家。但是事实上这种情况是很少的，很多架构师可能会面对另外一个新的项目，比如说你原来做汽车制造，现在让你做金融的，那你该怎么办？所以我们一般的做法是，如果一个大的公司、大的团队，我们会有专门的领域专家，由领域专家来负责业务这块，或者由客户来负责业务这块。但是我们的架构师也必须要对业务要有一定的了解，至少你要把一些行业的术语要搞清楚，这样你才能够和你的客户和领域专家在沟通上没有任何的问题，所以我不认为说，每个架构师都必须得成为一个业务专家，但是至少你在做这个架构之前，你必须要了解这个业务，了解这个行业。

如何评价系统架构的好坏？

从功能需求方面来说，如何去衡量架构师是成功的、是好的，其实很简单，就是要满足功能、满足客户需求。那我们可以利用一些方法，比如说需求矩阵、用需求跟踪这些方面，或者通过原形这些角度来和客户进行沟通，通过客户这边来了解我们这个架构方案在功能需求方面是否满足需求。然后我们可以利用一些方法，比如驱动设计，或者通过用力这些方式去驱动，把领域模式，也就是所谓的业务模型，把它建好。

从非功能性需求来说，其实是架构的一个难题，提到有安全方面、性能方面、可扩展性、可伸缩性，要求都很多。比如我们现在，都知道像Twitter、FaceBook，他们的业务都很简单，像Twitter就很简单，我follow你，然后你去follow我，那业务很简单。

但是作为一个Twitter的架构师要求很高，要求最高的可能在性能、安全稳定性这块，因为访问的人很多，所以性能这块如何去衡量，就需要有一些衡量的指标，比如响应时间之类的。在业界有很多解决这种非功能性需求方面的通用的一些方法，比如从性能角度来说，一般是利用缓存，在硬件方面不能再高的改善的情况之下，最重要的可能就是利用缓存，不管是用普通的缓存，还是用分布式缓冲。另外就是考虑可伸缩性，通过集群的方式，增加服务器的方式来提高这种性能。这些东西呢，我们就是在做架构的时候，我觉得在前期就要考虑好。

而且我觉得还有一个方法，就是把每一个功能、非功能性的因素，在权衡或者评价这个架构是否合适的时候，可以把它的因素扩大化，比如原来客户只要求能够承担十万人同时上线，你可以把它放大，你放大到一百万人，当同时上线的人数达到一百万人的时候，这个架构会不会出问题，通过这样一种方式，就是把某一个因素扩大化，来衡量你的架构。另外一个预先做调研，预先做架构，架构这块我可以先做，先做出一个原形出来，架构的原形，我们通过一些测试手段，通过压力测试，这方面的一些测试手段，来权衡这个架构是否有问题。

如何来保持架构师技术的敏锐度？
编码也是能够提高他的技术敏锐度。写整个解决方案的大体上的一些编码，而不是抠具体的算法，一些细节的实现，比如说我甚至可以写一个框架性的东西出来，然后具体的实现由开发人员去填，另外比较困难的东西，可以由你来编码去解决。还有从面向对象的角度来说，你可以写一些基类或者抽象类，把一些共同的东西提取出来。如何保持敏锐度呢，首先编码这个角度来说，我们要随时磨炼，我知道像我们很多世界一流的，象Kent Beck、Martin Fowler这些人，他们每天都还在写代码，就是要提高这方面能力，如果长期不写，就有可能到真正去做项目的时候，碰到一个问题需要你来写的时候，你写不出来。

程序员如何走向架构师？前者指导建议：

第一个就是，要认清自己，就说你的特长是什么，你的性格，你自己要有充分的了解，如果你确实在协调能力方面、组织能力方面、口头表达能力方面、交流能力方面、抽象能力方面你达不到，你可以选择另外路子。而不是觉得架构师好，你就一定要去做，其实在这个行业有很多角色都是非常好的，走到最后成为专家照样是能够得到很好的事业；

第二个要认清目标，你的目标是什么。而且你这个目标有一个近期的短期和长期目标，你在近一年要做什么事情，过三年、五年你要达到一个什么样的高度；如果没有目标，那就意味着你不会去关注你周围的跟这个目标相关的事情。在心理学上有一个重要的法则叫吸引力法则，就说只有当你心里有所想，这些信息它才会来找你。

第三，要找到适合自己的方法，因为每个人的能力不一样，特长不一样，学习方法可能都不一样，那么你的方法是什么，你要找到。比如说你可以通过多去阅读源代码，阅读一些开源的项目，或者说你可以多看书，多做项目之后，你可以在网上多找一些相关的文档，这些都是一些好的学习方法，像我现在每天保持阅读网络上的一些文章，或者是阅读书籍，特别有的书籍，是一些很一流的，战斗在一线的架构师，写的一些心得体会的总结。有的东西，可能在我们做的项目根本就没办法碰得到，但是在将来的项目中有可能会碰到，如果你还寄希望于在将来的时候碰到问题的时候你再去找，那就会出现很大的问题。

第四，未雨绸缪，你要事先做好准备，打下坚实的基础；最后一个，我认为最重要的是，基础很关键，不要好高骛远，不要一下子我要成为架构师了，好，我现在就去面向对象思想我都不太了解，设计模式我都不太了解，好，我现在就去搞架构模式，我去做架构的研究，我去分析这些架构的整个实现的原理，你根本就没有办法去掌握，所以你先要脚踏实地的先把最关键、最基础的东西先掌握好，就像我刚才说的要先专后博。先把这个东西研究的很透，而且不要抱着一个思想，就说我知道了就行了，要知其然，而不知其所以然，这样就会有很大的问题，我们要去把它研究透。包括像现在，就拿C#这种语言来说，你可能觉得这门语言你很清楚了，但事实上这个C#里面，涉及到框架的，比如说PC垃圾回收怎么运行机制，内存的管理是怎么去管理的，多线程是怎么处理的，并发是怎么去解决的，有很多很多东西需要深入的去分析，而不是盲目的知道C#的语法就够了，这五点对于开发者来说是一个比较重要的，应该说是比较重要的一个能力。

学习是很重要的一个层面，我们说形成知识技能是不够的，一定要让它应用并且形成自己的智慧，这才是有价值的。培根说了知识就是力量，那发展到今天，我们越来越发现实际上，就像彼得?德鲁克说的，知识本身这个它不产生价值，哪怕它在我们脑海里装的太多太多，只是知识而已，只是装在脑袋里的知识，东西而已，让它产生价值最佳的方式是什么？应用和分享知识。

即使你有好用的锤子，也不要把身边所有东西都当成钉子。在快速变更的现代科技社会，经验法则不会一直适用。传统智慧说永远不要在数库里面实现业务逻辑。为何这个说法传播如此广泛？大多数架构师都有类似经验，这会导致原始数据库在硬件方面如巨兽般增长，无法运行，也非常难维护。

这个假冒克苏鲁恐怖神出现的原因是主要数据库平台常常缺乏两个重要而且立等可用的特性：横向划分数据库的能力（比如根据数据实体划分数据）和纵向划分数据库的能力（不同的数据库实体放入不同数据库中）。当然，我们可以自己建立这两种特性，但是数据库管理团队以外的人常常也想处理类似问题。对于DBA来说这是赖以生存的手段而不是用于解决问题的能力。也就是说，对数据库做划分或者队列的技术常常要存在于数据库之外，使得开发者需要自己处理协议转换、多种接口、数据集成等问题。

简单的事情有效果
简单说，任何需要超过三句话来解释给其他人的事情，都不会实际有效的工作。
简单解决方案的另一个效果是促使你思考，而多思多想总是好的。总之，朝着让系统应用更为简单的目标去迎接所有需求、定律以及标准，毫不留情的去掉所有导致系统缓慢的多余脂肪。

创新一定会有风险，因为有投入，而且产出是不可预知的，但是不创新的风险更大，因为如果你不创新，但不能保证我们的竞争对手也不创新，在竞争领域里，不能单单把眼光放到团队内，而是要放在整个市场，放在我们的竞争对手。就一句，创新有风险，不创新风险更大。