2008年九月月 发布的文章

小议架构师

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

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

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

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

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

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

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

无意中的Pair Programming

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

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

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

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

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

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

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats