这周我在两个会议场合听到“架构师”这个词。对于软件开发领域的人来说，"架构师"这三个字并不陌生，甚至很崇高。每当提到架构师的时候，大家眼睛都会放出羡慕和期待的光芒，因为众所周知的原因："架构师"对于搞技术的人来说，都是"大牛"的代名词。

就像不想当将军的士兵不是好士兵一样，不想当大牛的技术人员肯定也不是好的技术人员。

第一个谈到"架构师"的场合是在会议室和一位要好的同事讨论新项目的需求时，他感慨道："当初我还以为架构师有多厉害，现在我们都是架构师了，也没有经过什么专业培训，带一两个项目，项目里架构不都是自己设计出来的吗，在客户那照样运行的很好"。

第二个说到"架构师"的场合是今天，也同样是在会议室，和几个同事一起做一个性能测试方案的评审时。部门即将投标的一个系统，该系统有一个硬性指标就是系统的消息处理能力要达到x万条。针对该标，一位资深的老同事，也是我们开发部的副部长说：如果能搞定这个x万条技术方案的人才算是真正的架构师，我们在座的目前还都是‘伪架构师’。

说心里话，目前我自己还根本不够一个架构师的资格，自己的水平还浅的很。从上述两个场合来看，每个人对’架构师’这个角色的理解有不同。我曾经是这样理解一个架构师的：架构师一定要是一个技术大牛，既要专又要广，对计算机体系结构有着X光般透彻的理解；在某门语言方向上有着语言专家般的把握；对前沿技术有着鹰眼般敏锐的眼光，对操作系统、编译器、数据库、网络等都了如指掌，或者说无所不知；任何复杂的系统在他的大脑中都有精妙的技术解决方案。但现在看来，这种想法有些幼稚，也太理想化。

我开始质疑：技术大牛是否是“架构师”的充要条件呢？我们看看其他行业领域吧，比如说三峡工程、比如说神舟飞船系统工程、比如说阿联酋的迪拜塔等等。想像一下他们的架构师们是一些什么样的人呢？他们每天做的事情都有哪些呢？我想他们做的最多的应该不是技术。这里又回到了上面的问题，是否架构师一定就是技术大牛呢？我们看看拥有架构师头衔的名人：微软首席架构师-比尔.盖茨、网易首席架构师丁磊；没听说过比尔.盖茨亲手设计了Windows的内核，也没听说丁磊在网易的主流产品中亲自设计了什么什么架构；我们更多的是在媒体里看到他们对技术的理解，对未来产品方向的把握；当然了我们平时见到的架构师肯定没有这二位有名气，但是他们应该有些共同之处：他们集各种基础素质于一身，这些素质包括技术能力、沟通能力、管理技巧、业务分析能力、问题的分析和解决能力等。技术牛只是架构师的一个基本素质或者说基础条件之一，也就是说技术牛人不一定就能被称为架构师，而架构师可能在技术上有很高建树，但也不一定是如我最初理解的那种技术大牛。

除了上述那么多能力之外，其实架构师也是一般人，他们也许更擅长的是平衡的艺术，他们拥有更多的是沉淀后的经验，他们知道哪里是短板、哪里是硬伤、哪里是死穴，他们的魅力在于他们的智慧，他们给人的感觉是热情中却不乏稳重，这样的人才真正值得"架构师"这个称号。

Pair Programming, 结对编程是敏捷开发中一个重要的实践，并受到很多业界大师级人物的推崇。但是明知它对我们可能会很有帮助，但是如果推广、实践起来还是要突破各种束缚的，心理上的、流程规范上的等等。我想也许这也或多或少也和公司或者部门的开发文化有些关系。我很想去尝试，但是一直没有找到一个很好的机会，也没有找到"心仪"的Partner。

今天上午恰好要完成一个脚本的编写，这是一个升级产品时使用的自动升级脚本，基础接口在上个月组内的一个同事已经完成了，并经过了大家的评审，认为可行。今天我就是要利用他的这个基础shell函数库来完成我的自动升级脚本的整理。

时间久了，那点关于这个脚本的模糊记忆早已经不存在了，很多细节我需要向我的那位同事请教。本打算找间会议室，坐在一起讨论的，后来发现会议室也被人占领了。上午的计划就是完成这个脚本，计划既然定下来了，就得执行，提高执行力一直是我这阶段的目标之一。就这样，我把这位同事叫到跟前，我们找了一块还算空旷和僻静的办公区坐了下来。我把我的想法向他做了陈述，告诉他我们一起完成这个脚本的初稿。我来掌控笔记本。按照以前我们升级的步骤，我们一步一步来实现脚本的功能，中间有自己不能确认的问题，就将键盘交予他来确认；他的基础脚本当初没有经过详尽的系统测试，也是碰巧，我们在一起写代码的时候居然又发现了原有代码中两个不妥的地方。

Pair的确是会调动人的热情和积极性的。但前提是有一个良好的、适合二人的工作空间；我自己觉得转角的办公桌是不太适合Pair的，两个人坐在转角旁，估计一会就累了-手脚无法伸展。掌控键盘的一方要多与另一方沟通，保持另一方的精神一直集中在你们的工作上，人和人在一起还是很容易溜号儿的。

经过半个多小时的编写，初稿搞定；回想一下，如果我选择的是自己闷头写脚本，然后再让那位同事评审，势必牵扯出不少额外工作量的；而结对的这种方法的确帮我解决了这样的一个问题。

事后反思，觉得的确应该把这一活动看成是一种Pair Programming。虽然现在我对Pair的认识和实践还处于肤浅之状态，但我想万事万物都无定式，最适合的才是最好的，摸索出适合我们组开发的PP模式才是最重要的，还需要实践、积累以及让更多的人参与其中。