Code Wins

程序员，高级程序员，系统构架师 似乎已经成为一个IT从业人员的技术发展线路图了。

这里我要问一下 我们的架构师有多少时间在写代码，有多少时间在读代码。当然你的技术职位越高你所需要关心的细节问题就越少，但是如果你没有基本的代码阅读能力或者说压根都不关心细节，哪你所设计出来的构架又有多少说服力呢？如何能于程序员进行交流？如何能将这些设计落实到具体的代码上呢？

我心目中的构架师是既能统观全局，又能细致入微的领军人物。对于系统构架，他已烂熟于胸，简单几句话就能引领你直达问题关键。有时候我们读大师写的文章，就会有这样的感觉，他会把事件的来龙去脉向你细细道来，如同一盏明灯照亮问题的每个角落。

软件构架师是如何修炼出来的呢？哪些设计模式，设计思路是如何成为他思考的元素的呢？其实写代码就和写文章一样，如果想写得顺畅，一个是多读别人的文章吸取营养，一个就是多写文章，训练自己的文字表达。

我很喜欢我现在的职业程序员（Coder），我就是喜欢写代码。也许你会说写代码很枯燥，没有拿着PPT给客户做介绍或者做设计潇洒。我可以给你说一个例子来说明技术人员的交流，代码是最有效的手段。哦，在这里有个前提就是交流的双方都有很强的代码阅读能力。如果你在要写程序，你了解的细节越多，你处理问题的能力越强，如果只是把细节都封装在黑盒中，哪你只能把问题转发到厂商哪里的。而这是玩Open Source Hacker的大忌。他们想得既然我能看到代码，我就能弄清楚细节，我就能修改它。

Dan Diephouse 去年到北京和我们交流有关CXF设计的时候，他没有PPT，他的讲解工具就是Eclipse和一堆CXF的代码。当时他给我的感觉就是对代码超熟悉（因为RunTime的大部分代码是他写的），基本上我们要问的问题，他都能给我们指出对应的代码出处。 这不由使我想到了以前流传在英语考研班的一句神话，朱泰祺教授把整个牛津词典都背下来了。

在Dan Diephouse在北京的哪几天，我老是在想一个问题，他20几岁，化学工程专业毕业，为什么就能具备开发Xfire 或者说是具备 Service Framework的构架能力，是什么帮助他走到这一步呢？通过几天时间的接触，我似乎发现了一些线索。

一个是勤奋，他说他一个礼拜大概要工作60个小时（基本上是在家工作，省去很多路上奔波的时间）。

一个就是广泛涉猎OpenSource项目，阅读他们的code。在他向我们演示代码的时候，我看到他经常要开好几个项目，有axis，有Xfire，也有CXF。

再一个就是参加了很多技术会议 ，近年来的Java  One,  Apache  Conn ,  Eclipse Conn ...... 都有他的身影。

现在Dan Diephouse 除了经营自己的咨询公司以外，他已经是Mule的架构师，我相信他会走的更好。

另一个例子就是我最近的一项工作就是将CXF和Camel进行集成，虽然我对CXF有所了解，但是在开始的几天时间里，我对Camel几乎是从零开始，当时我无法给出具体的系统需求分析，更不要提给出相关的设计方案。于是我只能硬着头皮看文档，看代码，问问题，写测试。当我把一个个Demo测试调通了，当我仔细阅读并跟踪过Process的各项测。一个个系统需求开始明晰了，设计思路也有了，没多久code也出来了。

这时我突然明白了一个道理，我的设计不是从文档里跳出来的，是从不断的code reading，code tracing，code writing and refactoring中出来的，虽然开始的几天很痛苦，一旦你把思路理清，你就会有一种醍醐灌顶的感觉。 Coder是一个实践性很强的职业，你需要把具体的客户需求转换成为具体的代码，你需要不断测试优化你的代码。你整天和代码打交道，只有你多读多写，才能驾轻就熟，才能烂熟于胸。

我很喜欢IONA的一条口号 Code Wins. 于大家共勉。