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

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

技术架构师要有责任心

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

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

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

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

技术架构师要有坚持

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

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

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

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

做错了，怎么办？

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

要深入了解实际情况

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

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

     摘要: 我们在开发中，经常需要遍历一个目录下的所有文件，常用的办法就是使用一个函数递归遍历是常用的办法。但是递归函数的缺点就是扩展不方便，当然你对这个函数加入一个参数FileHandler，这样扩展性稍好一些，但是仍然不够好，比如说，不能根据遍历的需要中途停止遍历，加入Filter等等。我实现了一个FileIterator，使得遍历一个目录下的文件如何遍历一个集合中的元素一般操作。  阅读全文

在新项目中，除了一些框架所依赖的配置文件使用XML外，基本没有使用XML。JSON基本替代了原来XML在程序内的位置。在以前，我们不愿意使用一种私有的格式，于是选择了XML。选择XML的理由，可能是大家都用它，所以我们也用它。

XML是一种很好的技术，但是目前的情况来看，XML被滥用了，SOAP是XML被滥用的一种典型，程序内部的表示使用XML也是滥用的一种典型。看到的一种情况，一个对象toString使用XML格式输出，导致日志文件十分罗嗦，调试时，在watch窗口中看到一大堆<tag>。

在新项目中，认真考虑这种情况，找到了另外一种选择，那就是JSON。选择JSON的理由很充分：
1、JSON的解释性能要比XML要好，要简洁紧凑。
2、可读性要比XML好。JSON本身就是JavaScript的语法，和程序员的思维，而非文档编写的思维。
3、JavaScript原生支持，客户端浏览器不需要为此使用额外的解释器，在web环境中使用特别合适。

在java中使用json，目前需要注意一些情况：
1、目前开源的JSON-LIB代码质量不好，最好是在此基础之上修改一个版本，或者自己重新开发一个版本。
2、使用new Date的方式替代JSON-LIB中的{year:2007, month:12, ....}之类的方式
3、JSON-LIB中，object的propertyName在输出的时候，都带上""，例如{"name": "温少"}, 其中name是的双引号是不必要的，在输出时应该判断，不需要的就是就不加上""，减少网络流量。
4、JSON的解释器中，应该支持简单的表达式，例如new Date()、new Date(2939234723)之类的，这使得JSON的表达能力会更强一些。
5、JSON应该分两种，一种只支持简单格式，类似开源的JSON-LIB，一种是通过JavaScript解释器来实现的。后者在程序中传输数据时，能够得到更强大的表达能力，但是也会导致安全问题，需要慎重使用。

1、XP中的结对编程。XP编程中，有一些思想总结的很好，例如测试驱动，但又有极度的荒唐的就是结对编程。结对编程是我看到过的最荒唐最可笑的软件工程方法，两倍的投入，一半的产出，可谓事倍功半。以前看结对编程只是觉得荒唐可笑，后来看了李安的电影《断背山》，觉得以“断背”来形容结对编程最适合了，结对编程简直就是专门为“男同志”们度身定做的软件工程方法，你想一对“男同志”，每天手牵手背靠背进行“结对编程”，是多么“浪漫有趣”的事情。不过这只对“男同志”们的浪漫有趣，对工作本身一点也不有趣！
--------------

2、JDO投票闹剧（2004-2005）。一个通过黑客式静态AOP方式旁门左道实现的持久化技术JDO，竟然会被一些人追捧，这本身就是一个很荒唐的事情了。在JCP的投票中，JDO被否决了，这一点也不奇怪，奇怪的是投票结果出来之后的闹剧。一些人以“政治阴谋论”来说事，说JDO不被通过，是因为政治原因，而非技术原因，这个荒唐的理由竟然被社区的很多人相信了，一片声讨，JCP迫于压力，重新投票，通过了JDO相关的JSR。但是JDO并没有因此有一点点起色，一直沉沦至今。JDO通过静态AOP（enhance）的方式使得代码无法调试，就单这一点，就足以使JDO永远无法流行。

这件事情很明确表明两点：1)、不要相信一些技术作家的判断力；2)、普通的大众没有判断能力，会人云亦云。

当年荒唐的文章选录：
《程序员》2005年第2期 http://blog.csdn.net/gigix/archive/2005/01/21/262163.aspx
---------------

竟然64个annotation，没有分类，放在同一个package下，同一个package（javax.persistance）还有其他java文件，共有88个java文件。不看内容本身，单从表面，都觉得这是混乱不堪的事情。这是那个猪头的杰作？glassfish上下载的源码中，这些java文件似乎都没有author，估计也不好意思把名字放出来见人吧！

------

觉得对象关系存储方面一直没有突破，也没有好的产品出来，其中一个原因，就是从没有过优秀的工程师投身过这个领域。关系数据库为什么能够一直坚守领地，成为绝大多数商业应用的基石，其中一个原因就是有过大量的精英投身于此，包括两个图灵奖获得者。

关系数据库，为了描述关系，创造一门SQL语言，将关系一些操作，例如投影（select）、选择（where）、分组(group by)等等，抽象得形象易懂，功能强大。对于数据的操作，SQL语言是最强大，也是最方便的，也是最易于使用的。一些非程序员的IT从业人员，非计算机专业的人员都能够熟练掌握SQL。

OO和Relational都是伟大的技术，从计算机最高荣誉奖可以看出这两个技术的伟大。OO的图灵奖获得者是三个，Relational的图灵奖获得者是两个。

面向对象技术自1967年simula引进依赖，所想披靡，93年-98年从C++开始流行，然后到Java，成为主流编程技术。Relational没有OO那么辉煌，但是在数据存储方面的地位固如磐石，长期占据绝对的地位。

曾经OO技术涉足于数据存储领域，但终究没有成功。面向对象数据库的变现总是差强人意，面向对象的方式操作数据，总是不如使用关系那么方便，那么灵活，那么易于使用，那么好的性能。于是人们在数据存储和处理方面，不在青睐面向对象技术，而是仍然使用关系方式，使用SQL语言，使用关系运算操作数据。面向对象数据库成了昙花一现的东西，并且可能永远都不会再流行了。

OO成了主流编程技术，Relational占据了绝对的数据存储地位，这两大技术需要交互，需要桥接，这需要OR-Mapping。Relational虽然好，但我们也要与时俱进，所以也需要OR-Mapping。

但是，做OR-Mapping时，不积极吸取relational方式对数据处理的灵活性、方便性、简单性，而只强调Relational和对象之间的的Mapping，试图以面向对象的方式操作数据，这是错误的方向。以前的EJB、现在Hibernate、JPA都犯了同样的错误，试图以更面向对象的方式操作数据，从而导致复杂混乱的模型，这也是JPA的现状吧。例如user.getGroup()，目前的ORM试图以纯OO的方式操作数据，所引起的LazyLoad、n+1等问题，使得事情变得复杂而且混乱不堪。

一些开发人员，去学习Hibernate，不学习SQL，有人提倡，只需要了解面向对象编程技术，不需要了解关系技术，亦属于本末倒置。需求人员都会用的SQL语言，对数据操作最方便最简单最强大的SQL语言，竟然成了令人生畏的纸老虎，可笑啊。

-------------

以下是过去的一些业界浮躁不理智：

1、面向对象数据库。曾被热衷而吹捧，面向对象数据库的变现总是差强人意，面向对象的方式操作数据，总是不如使用关系那么方便，那么灵活，那么易于使用，那么好的性能。于是人们在数据存储和处 理方面，不在青睐面向对象技术，而是仍然使用关系方式，使用SQL语言，使用关系运算操作数据。面向对象数据库成了昙花一现的东西，并且可能永远都不会再 流行了。

2、JDO投票闹剧。2004-2005年，JDO的JSR在JCP投票被否决的，无聊者在Java社区以及媒体发起闹事，阴谋论其为政治谋杀，几大公司是的迫于形象，重新投票使得JDO被通过，但JDO这种静态AOP叫雕虫小计式技术，不单开发过程不方便，而且会使得"enhance"之后的代码不可调试。这完全是对开发者不友好的技术，没有前途的技术，竟然会有人为它在JCP投票不通过鸣不平。这件事情使得我更坚信一点，不要相信那些技术编辑的判断力。

3、AOP。也是最近这几年流行的一个名词了。起了一个和OOP相似的名字，但是和伟大的OOP相比，它完全不算是什么。AOP只是一种很小很小的技巧而已，静态的AOP是黑客式的插入代码，会导致代码不可调试，动态的AOP能力有限，AOP最常被引用例子“日志AOP”是不合适，有用的日志通常是精心设计的，AOP方式的日志在生产环境中基本上是不可用。OO这么多年，这么为伟大，人们总是希望自己能做点什么和伟大的OO相比，于是命名为AOP，这是一个可笑的名字，前些年还有人谈论面向对象的未来是面向事实，也是同样的可笑。AOP有价值，但它是一种小技巧，和名字不般配。

--------------

目前在流行，但是可能是不理智的技术：

1、hibernate之类的ORM，试图以面向对象方式操作数据，和面向对象数据库一样，重蹈覆辙。
2、Ruby，一个小脚本语言，只是因为动态类型、mixin之类的功能，还没有被证明有生产力，有效益可用的脚本语言，就被媒体吹到天上去。Ruby有价值，但是最终结果会离大家的期待相差甚远。

又是新年，我有了宏大的计划，有了宏大的目标。

我要创造一个伟大产品，开创一个新的技术时代！

我已经开始在做了，我一定会成功！

全球领先的在线记账及商务管理平台—金蝶“友商网”（www.youshang.com）正式上线！请立刻体验！

     摘要: 本文描述一种ID生成算法  阅读全文

     摘要: 比较java、C#的泛型语法和各自优缺点  阅读全文

     摘要: java 5之后提供优秀的并发库util.concurrent，.net中缺乏类似的功能。由于硬件体系发生了变化，多核时代来临，.NET中缺乏并发类库显然不合时宜。其中一个办法就是在往C#中移植java的util.concurrent。本文讲述移植的关键点之一，LockSupport.park实现的代码移植。  阅读全文