关于技术架构师的一些看法
作者:edream 来源:沉寂博客 时间:2008-09-10 12:20:00
很多人谈架构师,其实有两种架构师,一种是业务架构,一种是技术架构。我的经验和教训局限于技术架构,所以本文特指技术架构师。
毕业前一年,毕业后7年,大约8年的技术领域经验和教训,参加过大小项目若干,有被人传颂的成功经验,也有惨痛的失败教训。以下是我的一些看法。
技术架构师要有责任心
比如说,过去经历过的一个大项目(数百开发人员,基础引擎数十人),这个大项目有一个基础模块,早期设计不良,有比较严重的性能问题,结构混乱,职责不清,很多人早期就发现了这个问题,众所周知。但是一直没改,说法是,改动的成本太大了,其他的部分要跟着改。但是,越晚改定,付出的成本就会越多。这个基础组件的在随后导致了多个严重问题,包括性能问题(占用内存多),开发效率问题(结构混乱,使用麻烦),等等。多年后,还问起这个组件时候,相关的同事都说,某某组件太烂了,没办法改啦。经常会想起这件事,想这究竟为什么会这样,怎么解决他。责任心是其中最重要的问题,当时的技术架构师没有负责任把这件事情解决了,让他拖下去。
谈到技术架构师的素质,当然要技术功底深厚,但这是基本素质,不是关键素质。我认为技术架构师的关键素质是责任心。作为架构师,你来设计这个架构,它是你的心血,你要“爱”它,为它的长久发展打好基础,甚至牺牲一些短期利益。
我们都是在成长的,经常遇到机会,做超出自己能力范围的事情,架构师在设计第一个架构时,甚至第N个架构师时,都有可能是超出自己能力了,然后在实际的工作中,把能力逐步提高。早期的设计可能是不够好的设计,同时已经应用在实现中了,但是你的能力随后提升了,认识到其中的问题了,你需要改正它,改正是需要成本的,作为架构师,要有责任心,敢于承担责任,对过错负责,把他改过来。
很多项目的顽症都是没有人敢于承担责任留下来的!而作为架构师,就一定要负责任,为万世开太平!
技术架构师要有坚持
有一次,我做了技术架构方面的一个方案,要执行它,大家(包括一些经理)都持反对态度,但是我最终一意孤行,坚决推行,最终取得非常好的效果,成为这个技术架构中最关键的技术之一。
作为技术架构师,可能你在团队中技术把握能力最好,比其他人思考的更多。如果你相信你的技术决定一定正确,那你就坚决推行它,不顾政治,不顾诸神!
遇到不擅长的问题怎么办?
作为架构师,面临的问题多方面,总会又遇到不擅长的领域,这时候,找其他同事,征求他们的决定,一起制定方案,或者干脆完全把决定权交给擅长这方面的同事。一定不要不懂装懂,外行管内行。
做错了,怎么办?
总会有做错的事情,怎么办呢?不要太顾面子,少找借口,接受批评,迅速改进。挨打要立正!别人也不会因为你一个错误而否定你全部的。根据经验,做错了事情然后改进的人,通常更受重用。原因是,错误发生了,领导们知道这个问题的难度,你解决了,就说明你解决了一个有难度的问题。
要深入了解实际情况
Ivar Jacobson最近讲到技术架构师,说执行代码比宏观架构更重要。古今中外,有一个共同的道理,就是细节决定成败。也有说法是“魔鬼总是在细节中”。架构的一些问题总是反映在实现细节中,或者使用细节中。作为技术架构师,你最好能够经常阅读使用架构的开发人员的实际使用情况,打开工程,阅读代码,然后把程序跑起来,观察执行情况。在最近作的一个技术架构中,其中多项重要的技术方案,都是观察了开发人员的代码之后总结然后做的改进方案。