【51CTO独家特稿】他的数学成绩很糟糕，曾不只一次的得过F；他并不算聪明，21岁才进入哥本哈根商学院就读本科学位；他做过游戏网站的记者，还与人合伙开过公司；在20岁以前，他没写过一行程序代码。

51CTO开发频道年终巨献:架构师最怕程序员知道的十件事

他在2005年获得Google和O'Reilly举办的OSCON最佳Hacker大奖；2006年，他获得了年度最佳Web开发工具震撼大奖（Jolt Development Tools）；现在，他创建的框架成为Web开发的主流技术，并被Twitter、Hulu等大型Web2.0网站所采用；由于他的框架采用Ruby开发，从侧面推动了Ruby语言的发展，并使Sun紧急上马推出JRuby。

David Heinemeier Hansson

他就是Ruby on Rails的创始人David Heinemeier Hansson；一般，Ruby程序员将Ruby on Rails称为RoR，将David Heinemeier Hansson称为DHH。

37signals和Basecamp

2004年，哥本哈根商学院的大三学生DHH接到一个来自美国芝加哥的电话，他在37signals公司的合伙人计划上马一个叫Basecamp的项目；和37signals的其他项目一样，Basecamp也是一个基于Web的项目，它试图解决项目因缺少图表、曲线图或者报告而失败的现象，简单的说，Basecamp是一个沟通和协作平台；唯一不同的是，37signals之前都是为客户开发的外包项目，Basecamp将是他们第一个自己的产品。

听上去是个不错的项目，但问题是37signals目前只有两个优秀的设计师和一个半路出家的程序员，而目前，这个程序员还在大洋彼岸的哥本哈根拿着电话暗自兴奋。

几天后，带着两年PHP开发经验和学校里学来的一点J2EE课程，DHH来到美国；他将面对的是一个极富挑战的项目，繁琐的需求、众多的功能模块、复杂的接口和紧迫的交付日期。

把复杂的问题简单化

DHH很自信，他知道自己没有出色的数学天赋，没有丰富的项目经验，没有大师级的计算机功底；但他对自己的另一项能力很自信，把复杂的问题简单化。早在编写PHP程序时DHH就开发过一套框架，目的是使PHP能在项目中变得简洁快速，将程序的界面、控制和数据分离开来，方便团队间的协作和维护。

对编程开始感到愤怒

PHP每次HTTP请求都要初始化资源，这个过程的开销非常大。尽管PHP解析器的运行速度快速且没有缺陷，但一旦使用框架，那么每次请求时初始化整个框架使性能的下降非常厉害，当使用一个很复杂的PHP框架的结果就是整体性能严重下降；同时，PHP语言本身的问题造成了PHP添加跨请求的高级特性相当困难，这是PHP本身一个很大的限制，但是反过来说，正是这种限制使得PHP始终保持在一个比较简单的Web语言上面，而正是这一点才是PHP得以成为互联网流行Web编程语言的原因。这是一个复杂的问题，时至今日，究竟谁才是最适合Web开发的语言一直存在争论，详细请参考51CTO的策划专题《大师论战Web开发 Ruby和PHP谁将称王?》

源自底层的弱点似乎正在预言着PHP并不完全适合正在袭来的Web2.0大潮和37signals的Basecamp项目。DHH开始思考，他要找到一种简单的方法完成真个项目，灵活、简洁和快速是他的终极要求。他在朋友的怂恿下开始接触Ruby，很快，他开始喜欢Ruby，因为他发现，Ruby可以把复杂的问题简单化。在51CTO之前的一篇《Ruby on Rails入门之道》报道中，DHH提到：“我是在对编程开始感到愤怒的时候开始学习Ruby的。我想做真实的东西，而不仅仅是一个玩具程序”。

Ruby

Ruby的开发效率高的惊人,更重要的是它的语法简洁优雅,DHH看着自己用Ruby一周时间写出的功能比用PHP做一个月还要多；之后，他开始尝试将自己的PHP框架用Ruby做移植,并在其中加上J2EE的一些东西。很快，他将自己的兴奋传达到37signals并说服Basecamp团队使用Ruby进行开发。

两个月后，DHH开发出了基于Ruby的框架；又过了两个月，整个Basecamp产品完成。好事接二连三，在DHH对自己架构的框架异常兴奋的同时，37signals的第一个产品面Basecamp一发布就引起了轰动，全世界40多个国家的人值得开始使用，当时，有人认为它是世界是最好的Web应用程序。

同时，Basecamp也引起了开发界的关注，众多Web工程师试图找出BaseCamp快速响应、安全稳定的秘密。DHH决定将Ruby框架从Basecamp里剥离出来,让更多人应用自己架构的框架并受益于高开发效率，这个框架就是Rails。

Ruby on Rails的简单之道

DHH对Rails的解释是“最近的一条路”。从Rails这个名字我们可以看出，DHH希望软件开发可以沿着一个正确的轨迹不断向前，告别复杂的左转右转和讨厌的红灯；他也是按照这样的想法架构整个Rails。如果你使用过Rails，其脚手架的功能一定让你兴奋。我们可以通过Rails脚手架创建一套样式的行为和模板，它们可以让你在具体的模型中操纵数据异常简单，同时，脚手架还提供了允许在数据库中插入、更新和删除记录的方法与页面。

Ruby on Rails创始人DHH

回想一下你在PHP和Java中的复杂的配置和数据库操作，这些在Rails里竟如此简单。当然，Ruby on Rails不只强大在数据库方面，除了可以使用Active Record进行数据库操作，还可以使用Active Record和Action Pack进行模型和视图的开发；除在基础Web开发方面的简单化，在Ajax交互支持、扩展和部署方面，Rails同样简单易行。

Ruby on Rails因为可以把复杂的问题简单化而变得流行。2004年7月，DHH发布了Rails的第一个版本；第一周Ruby on Rails的下载量是2000次，，第二周下载量翻了好几倍，之后几个月间，整个社区似乎都在为Ruby on Rails的诞生而兴奋！目前，Ruby on Rails已经进阶主流Web开发技术，使用其开发的各种网站不计其数，详细可以参考51CTO之前的报道《TOP50用Ruby on Rails开发的网站》

随着Ruby on Rails的成功，DHH也成为一些开发者的偶像，一个数学得F的软件精英，一个20岁前没写过一行代码的程序天才，一个把复杂问题简单化的架构大师。

【51CTO独家特稿】架构师的沟通方向与项目经理相比，还是有一定的区别。比如项目经理有很大一部分时间需要与客户进行沟通，进一步弄清需求。而架构师的沟通主要在于开发团队内部，一种纯技术上的沟通。这也是作为技术领路人的架构师，最日常的工作。

51CTO开发频道年终巨献:架构师最怕程序员知道的十件事

当架构师对整个系统分析完毕，有一些架构师喜欢昏天黑地的奋斗几天，然后写出一本厚厚的架构书扔给程序员。在此之后就不做过多的交流与沟通，“具体实现？那是程序员的事情，我怎么能去干涉他们呢？”其实在这里，这位架构师就犯了错误，他并没有将自己真正融入开发团队中，而是以一种高高在上的救世主姿态出现。其实架构师未必就是神人，很多错误还是要大家一起来研究来解决的。

究竟怎样才能是一名合格的架构师，成为一名真正能说会道的程序员呢？首先自然是沟通要清晰明了，平和待人。架构师不能将自己锁在自己的象牙塔上，颐指气使的对程序员发号施令。这样的态度必然遭到程序员的愤恨，大家都是一样的技术人员，只是分工的不同，为什么要受气呢？

做到人性化的沟通，需要我们在平时就进行培养。写出大部头的架构书，有的时候并没有用VISIO画出的简单架构图好理解。人对图形理解远远大于对文字的理解，直观简单的UML图可以极大的方便程序员理解架构师的意图。其次，可以召开小范围的技术人员会议，大家一起来讨论，一起理解架构师真正的意图。甚至就是一块小白板，几支笔就能把问题摆清楚，讲明白，统一意见后的团队必然干劲十足，再不会出现互相推诿的情况。

架构师就相当于一支球队的主教练，如何将自己布置的战术交到执行的球员，也就是开发人员的脑袋里，是关乎胜利的关键。那么怎样才能成为一名能说会道的程序员呢？

在一般人的印象里，程序员都是一群略显呆滞，沟通能力不强的技术狂人。逻辑思维非同常人，但就是倒不出来。有些人通过找女朋友作为旁证，连经济适用男中的定义原型都是IT人士，月薪4000以上，不善言谈，最后娶一剩女为妻。看来我等程序员，真的只能被人如此定义了。虽说架构师技术层面上的东西与前例不可同日而语，但是也看到沟通能力上，程序员还有很大的发展空间。

其实很多程序员都是善于谈吐的，木讷的形象只是人们的误解。但是如何来改变呢？首先我们需要更多的感性思考，说话时也要注重别人的感受，尊重对方才能更好的交流。微软MVP陈广琛在与51CTO编辑谈到程序员沟通能力时，曾说道：“很多程序员总能列出一堆的理由来，说明为什么自己不适合学习或者不需要掌握某项与程序无关的技能，例如说演讲、英语、设计等等。但其实问题并没有那么复杂，你需要考虑的只是多学一项技能是否对你的职业发展更有利，只要你愿意，没什么是不能改变的。”

51CTO总结：架构师不是油腔滑调的程序员，但是一句话都憋不出来的程序员，是做不好架构师的。

本文为《架构师害怕程序员知道的十项技能》中的沟通能力篇。

【51CTO独家特稿】架构师，听起来是如此神秘的一个称号。尤其是在开发领域刚入门不久的菜鸟级程序员眼中，架构师都是高手，都是牛人，都是如此高高在上的存在。

51CTO开发频道年终巨献:架构师最怕程序员知道的十件事

不过，在搞了四、五年编程之后，程序员们往往早已失去了当年对这些“高级”职位的神秘感，甚至会对自己所在项目的架构师抱怨不已，背后里称他们是一群水王。所以有江南白衣曾撰文述说：“国内的架构师到了三十岁以后很多就往理论上跑，而国外的架构师在往上发展的同时保持下面的编程体验，所以国内多水王，而国外则多大师。”

这就是我们今天这篇文章的论题：一个优秀的软件架构师，首先一定是一个出色的程序员。

这句话按照Fred George先生的话来说，那就是“不编程的架构师的职业生涯是短暂的”。他说这句话的背景主要是针对有些架构师的设计与实现有断层的问题而言的，因为如果架构师不去实践，只是想当然的认为“没问题，这个想法能实现”，那么对于项目的落实而言是个很大的隐患。支付宝架构师冯大辉也表示过，架构师是一个比较“虚”的岗位，主要的问题都在“落地”的过程中。

而一个架构师确认一个想法究竟能不能落地的最直接的方法，就是自己编写代码，尝试“实现一个系统最难实现的一部分”（Fred George）。看看Fred，他自己就是最好的示范：年纪一大把了，仍然每天都在编写代码。事实上，我们可以列举出一个长长的顶级架构师的列表，你会发现他们没有一个不是顶级的程序员。

 
我们可以列举出一个长长的顶级架构师的列表，你会发现他们没有一个不是顶级的程序员

不过这在逻辑上或许没有多少说服力，因为似乎这并不能证明一位资深架构师凭自己的经验感觉不能够知道一个想法能不能落实。如果你觉得上面这些只是某些西方老头儿对编程的古怪癖好，那么不妨看看eBay的架构师Randy Shoup先生是如何总结架构师在项目中的职责的：

1. 产品团队要做一个新产品，架构师开工了。架构师要帮助产品团队把可行性、技术需求以及权衡取舍等因素一一剖析清楚。

2. 技术需求出来了，架构师的主要工作开始了：设计整体的技术实现步骤。Randy在后面补充说“大多数成功的架构师都喜欢与其他团队成员一同完成架构和设计这一块的工作”，而认为自己应独自完成这个步骤则是新手架构师常见的误区。

3. 与开发团队一起，完成设计与实施的细节

4. 与开发团队和运维团队一起，完成部署的过程

5. 与运维团队一起，进行部署之后的维护和故障排除

只要稍微思考一下，就会明白此举的重要性。如果一个架构师靠命令管理开发团队，告诉他们“要实现这个模块”，“要实现那个功能”，而团队也尝试照办。可是或许是架构师的要求太高了，或许是团队的开发实力不够，团队成员便会向架构师求助：您看这个我们不知道如何实现，您能否指导一下？架构师可能知道怎么处理，也可能没有仔细思考过这个问题，但又觉得自己做大事者不拘泥于小节也，于是一皱眉头扔下一句：这是你们的事，你们自己解决！

然后就是矛盾的开始了。架构师只觉得团队技术不够，而团队则对架构师愈发不满。项目黄了不说，开发团队中也会传出各种说法，比如说“此君其实是个一行代码也不会写的大忽悠！”

综上所述，便映证了Fred的那句断言：“不编程的架构师的职业生涯是短暂的”。一个架构师不仅要会写代码，还必须要能够写出自己设计的系统中最难实现的那段代码。这样他才能够放心的把“落地”的这个重担交给开发团队来做。

让我用Fred的这句话做为本篇的总结：“一个架构师的价值在于，他不仅能看到系统的美，而且能够在建造系统的时候能够把这些美创造出来。”

是的，每个好架构师都是一位出色的程序员。

本文为《架构师害怕程序员知道的十项技能》中的优秀程序员篇。