ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 技术架构师要有责任心 [网络]

技术架构师要有责任心 [网络]

原创 Linux操作系统 作者:leniz 时间:2008-11-23 15:00:42 0 删除 编辑

From IT168.com

很多人谈架构师,其实有两种架构师,一种是业务架构,一种是技术架构。我的经验和教训局限于技术架构,所以本文特指技术架构师。

毕业前一年,毕业后7年,大约8年的技术领域经验和教训,参加过大小项目若干,有被人传颂的成功经验,也有惨痛的失败教训。在以前一直作为技术尖子,在不同的领域逐步填充各方面的知识,最近一年开始做架构设计。以下是我的一些看法。

技术架构师要有责任心

比如说,过去经历过的一个大项目(数百开发人员,基础引擎数十人),这个大项目有一个基础模块,早期设计不良,有比较严重的性能问题,结构混乱,职责不清,很多人早期就发现了这个问题,众所周知。但是一直没改,说法是,改动的成本太大了,其他的部分要跟着改。但是,越晚改定,付出的成本就会越多。这个基础组件的在随后导致了多个严重问题,包括性能问题(占用内存多),开发效率问题(结构混乱,使用麻烦),等等。多年后,还问起这个组件时候,相关的同事都说,某某组件太烂了,没办法改啦。经常会想起这件事,想这究竟为什么会这样,怎么解决他。责任心是其中最重要的问题,当时的技术架构师没有负责任把这件事情解决了,让他拖下去。

谈到技术架构师的素质,当然要技术功底深厚,但这是基本素质,不是关键素质。我认为技术架构师的关键素质是责任心。作为架构师,你来设计这个架构,它是你的心血,你要“爱”它,为它的长久发展打好基础,甚至牺牲一些短期利益。

我们都是在成长的,经常遇到机会,做超出自己能力范围的事情,架构师在设计第一个架构时,甚至第N个架构师时,都有可能是超出自己能力了,然后在实际的工作中,把能力逐步提高。早期的设计可能是不够好的设计,同时已经应用在实现中了,但是你的能力随后提升了,认识到其中的问题了,你需要改正它,改正是需要成本的,作为架构师,要有责任心,敢于承担责任,对过错负责,把他改过来。

很多项目的顽症都是没有人敢于承担责任留下来的!而作为架构师,就一定要负责任,为万世开太平!

技术架构师要有坚持

有一次,我做了技术架构方面的一个方案,要执行它,大家(包括一些经理)都持反对态度,但是我最终一意孤行,坚决推行,最终取得非常好的效果,成为这个技术架构中最关键的技术之一。

作为技术架构师,可能你在团队中技术把握能力最好,比其他人思考的更多。如果你相信你的技术决定一定正确,那你就坚决推行它,不顾政治,不顾诸神!

遇到不擅长的问题怎么办?

作为架构师,面临的问题多方面,总会又遇到不擅长的领域,这时候,找其他同事,征求他们的决定,一起制定方案,或者干脆完全把决定权交给擅长这方面的同事。一定不要不懂装懂,外行管内行。

做错了,怎么办?

总会有做错的事情,怎么办呢?不要太顾面子,少找借口,接受批评,迅速改进。挨打要立正!别人也不会因为你一个错误而否定你全部的。根据经验,做错了事情然后改进的人,通常更受重用。原因是,错误发生了,领导们知道这个问题的难度,你解决了,就说明你解决了一个有难度的问题。

要深入了解实际情况

Ivar Jacobson最近讲到技术架构师,说执行代码比宏观架构更重要。古今中外,有一个共同的道理,就是细节决定成败。也有说法是“魔鬼总是在细节中”。架构的一些问题总是反映在实现细节中,或者使用细节中。作为技术架构师,你最好能够经常阅读使用架构的开发人员的实际使用情况,打开工程,阅读代码,然后把程序跑起来,观察执行情况。在最近作的一个技术架构中,其中多项重要的技术方案,都是观察了开发人员的代码之后总结然后做的改进方案。

技术架构师要面临的技术细节很多,例如分层细节,数据库命名规范,代码规范,spring配置文件管理,ibatis配置文件管理,日志输出规范,findbugs定期检查,作Eclipse插件把一些技术方案固化下来,经常维护wiki知识库,作code review,整理项目依赖,日构建制品输出管理,等等。每个具体项目的细节都不一样,细节处理不好,就会产生“魔鬼”。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/554557/viewspace-501488/,如需转载,请注明出处,否则将追究法律责任。

上一篇: 我的老BLOG
下一篇: BW Query RRI Filter
请登录后发表评论 登录
全部评论

注册时间:2008-05-31

  • 博文量
    448
  • 访问量
    1113548