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

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。