?1CTO独家特稿】他的数学成l很p糕Q曾不只一ơ的得过FQ他q不聪明,21岁才q入哥本哈根商学院就LU学位;他做q游戏网站的记者,q与人合伙开q公司;?0岁以前,他没写过一行程序代码?/p>
他在2005q获得Google和O'Reilly丑֊的OSCON最佳Hacker大奖Q?006q_他获得了q度最佳Web开发工具震撼大奖(Jolt Development ToolsQ;现在Q他创徏的框架成为Web开发的L技术,q被Twitter、Hulu{大型Web2.0|站所采用Q由于他的框枉用Ruby开发,从侧面推动了Ruby语言的发展,qSun紧急上马推出JRuby?/p>
他就是Ruby on Rails的创始hDavid Heinemeier HanssonQ一般,RubyE序员将Ruby on RailsUCؓRoRQ将David Heinemeier HanssonUCؓDHH?/p>
37signals和Basecamp
2004q_哥本哈根商学院的大三学生DHH接到一个来自美国芝加哥的电(sh)话,他在37signals公司的合伙h计划上马一个叫Basecamp的项目;?7signals的其他项目一PBasecamp也是一个基于Web的项目,它试图解决项目因~少图表、曲U图或者报告而失败的现象Q简单的_Basecamp是一个沟通和协作q_Q唯一不同的是Q?7signals之前都是为客户开发的外包目QBasecamp是他们W一个自q产品?/p>
听上L个不错的目Q但问题?7signals目前只有两个优秀的设计师和一个半路出家的E序员,而目前,q个E序员还在大z彼岸的哥本哈根拿着?sh)话暗自兴奋?/p>
几天后,带着两年PHP开发经验和学校里学来的一点J2EE评QDHH来到国Q他面对的是一个极富挑战的目Q繁琐的需求、众多的功能模块、复杂的接口和紧q的交付日期?/p>
把复杂的问题单化
DHH很自信,他知道自己没有出色的数学天赋Q没有丰富的目l验Q没有大师的计机功底Q但他对自己的另一能力很自信Q把复杂的问题简单化。早在编写PHPE序时DHH开发过一套框Ӟ目的是PHP能在目中变得简z快速,程序的界面、控制和数据分离开来,方便团队间的协作和维护?/p>
对编E开始感到愤?/strong>
PHP每次HTTPh都要初始化资源,q个q程的开销非常大。尽PHP解析器的q行速度快速且没有~陷Q但一旦用框Ӟ那么每次h时初始化整个框架使性能的下降非常厉宻I当用一个很复杂的PHP框架的结果就是整体性能严重下降Q同ӞPHP语言本n的问题造成了PHPd跨请求的高Ҏ(gu)相当困难,q是PHP本n一个很大的限制Q但是反q来_正是q种限制使得PHP始终保持在一个比较简单的Web语言上面Q而正是这一Ҏ(gu)是PHP得以成ؓ互联|流行Web~程语言的原因。这是一个复杂的问题Q时至今日,I竟谁才是最适合Web开发的语言一直存在争论,详细请参?1CTO的策划专题?a >大师论战Web开?Ruby和PHP谁将U王??/p>
源自底层的弱点似乎正在预a着PHPq不完全适合正在袭来的Web2.0大潮?7signals的Basecamp目。DHH开始思考,他要扑ֈ一U简单的Ҏ(gu)完成真个目Q灵zR简z和快速是他的l极要求。他在朋友的怂恿下开始接触RubyQ很快,他开始喜ƢRubyQ因Z发现QRuby可以把复杂的问题单化。在51CTO之前的一?a >Ruby on Rails入门之道》报道中QDHH提到Q?#8220;我是在对~程开始感到愤怒的时候开始学习Ruby的。我惛_真实的东西,而不仅仅是一个玩L?#8221;?/p>
Ruby
Ruby的开发效率高的惊?更重要的是它的语法简z优?DHH看着自己用Ruby一周时间写出的功能比用PHP做一个月q要多;之后Q他开始尝试将自己的PHP框架用Ruby做移?q在其中加上J2EE的一些东ѝ很快,他将自己的兴奋传辑ֈ37signalsq说服Basecamp团队使用Rubyq行开发?/p>
两个月后QDHH开发出了基于Ruby的框Ӟ又过了两个月Q整个Basecamp产品完成。好事接二连三,在DHH对自己架构的框架异常兴奋的同Ӟ37signals的第一个品面Basecamp一发布?yu)引起了轰动Q全世界40多个国家的h值得开始用,当时Q有为它是世界是最好的Web应用E序?/p>
同时QBasecamp也引起了开发界的关注,众多Web工程师试图找出BaseCamp快速响应、安全稳定的U密。DHH军_Ruby框架从Basecamp里剥d?让更多h应用自己架构的框架ƈ受益于高开发效率,q个框架是Rails?/p>
Ruby on Rails的简单之?/strong>
DHH对Rails的解释是“最q的一条\”。从Railsq个名字我们可以看出QDHH希望软g开发可以沿着一个正的轨迹不断向前Q告别复杂的左{双{和讨厌的U灯Q他也是按照q样的想法架构整个Rails。如果你使用qRailsQ其脚手架的功能一定让你兴奋。我们可以通过Rails脚手架创Z套样式的行ؓ和模板,它们可以让你在具体的模型中操U|据异常简单,同时Q脚手架q提供了允许在数据库中插入、更新和删除记录的方法与面?/p>
回想一下你在PHP和Java中的复杂的配|和数据库操作,q些在Rails里竟如此单。当ӞRuby on Rails不只强大在数据库斚wQ除了可以用Active Recordq行数据库操作,q可以用Active Record和Action Packq行模型和视囄开发;除在基础Web开发方面的单化Q在Ajax交互支持、扩展和部v斚wQRails同样单易行?/p>
Ruby on Rails因ؓ可以把复杂的问题单化而变得流行?004q?月,DHH发布了Rails的第一个版本;W一周Ruby on Rails的下载量?000ơ,Q第二周下蝲量翻了好几倍,之后几个月间Q整个社Z乎都在ؓRuby on Rails的诞生而兴奋!目前QRuby on Rails已经q阶LWeb开发技术,使用其开发的各种|站不计其数Q详l可以参?1CTO之前的报道?a >TOP50用Ruby on Rails开发的|站?/p>
随着Ruby on Rails的成功,DHH也成Z些开发者的偶像Q一个数学得F的Y件精英,一?0岁前没写q一行代码的E序天才Q一个把复杂问题单化的架构大师?/p>
?1CTO独家特稿】架构师的沟通方向与目l理相比Q还是有一定的区别。比如项目经理有很大一部分旉需要与客户q行沟通,q一步弄清需求。而架构师的沟通主要在于开发团队内部,一U纯技术上的沟通。这也是作ؓ技术领路h的架构师Q最日常的工作?/p>
当架构师Ҏ(gu)个系l分析完毕,有一些架构师喜欢昏天黑地的奋斗几天,然后写出一本厚厚的架构书扔l程序员。在此之后就不做q多的交与沟通,“具体实现Q那是程序员的事情,我怎么能去q涉他们呢?”其实在这里,q位架构师就犯了错误Q他q没有将自己真正融入开发团队中Q而是以一U高高在上的救世d态出现。其实架构师未必是hQ很多错误还是要大家一h研究来解决的?/p>
I竟怎样才能是一名合格的架构师,成ؓ一名真正能说会道的E序员呢Q?/strong>首先自然是沟通要清晰明了Q^和待人。架构师不能自己锁在自q象牙塔上Q颐指气使的对程序员发号施o。这L态度必然遭到E序员的愤恨Q大安是一L技术h员,只是分工的不同,Z么要受气呢?
做到人性化的沟通,需要我们在qxp行培充R写出大部头的架构书Q有的时候ƈ没有用VISIOd的简单架构图好理解。h对图形理解远q大于对文字的理解,直观单的UML囑֏以极大的方便E序员理解架构师的意图。其ơ,可以召开范围的技术h员会议,大家一h讨论Q一L解架构师真正的意图。甚臛_是一块小白板Q几支笔p把问题摆清楚Q讲明白Q统一意见后的团队必然q劲十Q再不会出现互相推诿的情c?/p>
架构师就相当于一支球队的Ll,如何自己布|的战术交到执行的球员,也就是开发h员的脑袋里,是关乎胜利的关键。那么怎样才能成ؓ一名能说会道的E序员呢Q?/p>
在一般h的印象里Q程序员都是一略昑֑滞,沟通能力不强的技术狂人。逻辑思维非同思hQ但是倒不出来。有些h通过扑֥朋友作ؓ旁证Q连l济适用男中的定义原型都是IT人士Q月?000以上Q不善言谈,最后娶一剩女为妻。看来我{程序员Q真的只能被人如此定义了。虽说架构师技术层面上的东西与前例不可同日而语Q但是也看到沟通能力上Q程序员q有很大的发展空间?/p>
其实很多E序员都是善于谈吐的Q木L形象只是Z的误解。但是如何来改变呢?首先我们需要更多的感性思考,说话时也要注重别人的感受Q尊重对Ҏ(gu)能更好的交流。微软MVP陈广琛在?1CTO~辑谈到E序员沟通能力时Q曾说道Q?#8220;很多E序员总能列出一堆的理由来,说明Z么自׃适合学习或者不需要掌握某与E序无关的技能,例如说演讌Ӏ英语、设计等{。但其实问题q没有那么复杂,你需要考虑的只是多学一Ҏ(gu)能是否对你的职业发展更有利,只要你愿意,没什么是不能改变的?#8221;
51CTOȝQ架构师不是油腔滑调的程序员Q但是一句话都憋不出来的E序员,是做不好架构师的?/p>
本文为《架构师x程序员知道的十Ҏ(gu)能》中的沟通能力篇?/p>
?1CTO独家特稿】架构师Q听h是如此神U的一个称受尤其是在开发领域刚入门不久的菜鸟E序员眼中,架构师都是高手,都是牛hQ都是如此高高在上的存在?/p>
不过Q在搞了四、五q编E之后,E序员们往往早已失去了当q对q些“高”职位的神U感Q甚至会对自己所在项目的架构师抱怨不Ԍ背后里称他们是一水王。所以有江南白衣曾撰文述_“国内的架构师C三十岁以后很多就往理论上跑Q而国外的架构师在往上发展的同时保持下面的编E体验,所以国内多水王Q而国外则多大师?#8221;
q就是我们今天这文章的论题Q一个优U的Y件架构师Q首先一定是一个出色的E序员?/p>
q句话按?a >Fred George先生的话来说Q那是“不编E的架构师的职业生是短暂的”。他说这句话的背景主要是针对有些架构师的设计与实现有断层的问题而言的,因ؓ如果架构师不d践,只是惛_然的认ؓ“没问题,q个x能实?#8221;Q那么对于项目的落实而言是个很大的隐(zhn)?a >支付宝架构师冯大?/a>也表CQ架构师是一个比?#8220;?#8221;的岗位,主要的问题都?#8220;落地”的过E中?/p>
而一个架构师认一个想法究竟能不能落地的最直接的方法,是自己~写代码Q尝?#8220;实现一个系l最隑֮现的一部分”QFred GeorgeQ。看看FredQ他自己是最好的CQ年U一大把了,仍然每天都在~写代码。事实上Q我们可以列丑և一个长长的架构师的列表Q你会发C们没有一个不是顶U的E序员?/p>
我们可以列DZ个长长的架构师的列表Q你会发C们没有一个不是顶U的E序?/span>
不过q在逻辑上或许没有多说服力Q因Z乎这q不能证明一位资深架构师凭自ql验感觉不能够知道一个想法能不能落实。如果你觉得上面q些只是某些西方老头儿对~程的古怪癖好,那么不妨看看eBay的架构师Randy Shoup先生是如何ȝ架构师在目中的职责的:
1. 产品团队要做一个新产品Q架构师开工了。架构师要帮助品团队把可行性、技术需求以及权衡取舍等因素一一剖析清楚?/p>
2. 技术需求出来了Q架构师的主要工作开始了Q设计整体的技术实现步骤。Randy在后面补充说“大多数成功的架构师都喜欢与其他团队成员一同完成架构和设计q一块的工作”Q而认己应独自完成q个步骤则是新手架构师常见的误区?/p>
3. 与开发团队一P完成设计与实施的l节
4. 与开发团队和q维团队一P完成部v的过E?/p>
5. 与运l团队一Pq行部v之后的维护和故障排除
在这个过E中Q一个架构师臛_有一半以上的工作是需要与开发团队一赯行的。按照Randy的描qͼq是“一个架构师不能实施细节抛之脑?#8221;的体现。而且与开发团队一起工作,命o式的领导方式q不被推崇,一个架构师必须通过自己的个人媄响力来对开发团队进行指导工作。而什么是影响力?说的直白一些,是通过自己写代码以及和其他成员一起写代码Q来指导团队成员实现每个架构l节的思\?
只要E微思考一下,׃明白此D的重要性。如果一个架构师靠命令管理开发团队,告诉他们“要实现这个模?#8221;Q?#8220;要实现那个功?#8221;Q而团队也试照办。可是或许是架构师的要求太高了,或许是团队的开发实力不够,团队成员便会向架构师求助Q?zhn)看这个我们不知道如何实现Q?zhn)能否指导一下?架构师可能知道怎么处理Q也可能没有仔细思考过q个问题Q但又觉得自己做大事者不拘惔于小节也Q于是一q头扔下一句:q是你们的事Q你们自p冻I
然后是矛盾的开始了。架构师只觉得团队技术不够,而团队则Ҏ(gu)构师愈发不满。项目黄了不_开发团队中也会传出各种说法Q比如说“此君其实是个一行代码也不会写的大忽(zhn)!”
lg所qͼ便映证了Fred的那句断aQ?#8220;不编E的架构师的职业生是短暂的”。一个架构师不仅要会写代码,q必要能够写出自己设计的系l中最隑֮现的那段代码。这样他才能够放心的?#8220;落地”的这个重担交l开发团队来做?/p>
让我用Fred的这句话做ؓ本篇的ȝQ?#8220;一个架构师的h(hun)值在于,他不仅能看到pȝ的美Q而且能够在徏造系l的时候能够把q些创造出来?#8221;
是的Q每个好架构师都是一位出色的E序员?/p>
本文为《架构师x程序员知道的十Ҏ(gu)能》中的优UE序员篇?nbsp;