软件架构师之路
软件架构师之路
周恒
常和好友孙向晖探讨软件开发之道，他把我作为架构师推荐到程序员杂志，提笔良久却不敢下笔。虽然多年来一直负责开发浪潮软件的企业应用架构，却总觉软件架构师在软件行业中是一神圣的称号，所以不敢随便妄称架构师。
本文叙述了笔者工作以来的历程，穿插谈谈工作以来的一些关于架构师的体会。
尚在大学时候，非常崇拜那些技术天才，特别对求伯君前辈等以一己之力编写著名软件的前辈豪杰等佩服得五体 投地，期望有一天也能像他们那样成为大侠。无论黑天白夜，挥斥键盘程序人生，累了可以游戏中十步杀一人，何等自由与潇洒？
毕业后到公司，有了机器，抱床被子到办公室，静躺着躲过12点钟保安手电的扫射检查，就可以在里面通宵奋战了。两个月时间,也终于把自己打造成气质癫狂、头发蓬乱、脸色苍白、双眼通红、键盘敲得满屋响，具备技术高手的一切外表特征的狂人了。和大多数新工作的程序员一样，那时是比较喜欢搞纯技术的工作，隔壁办公室还有另外一位气质癫狂的战友，和我一样喜欢键盘敲得满屋响，闲暇时候常聊些技术话题，也都对写数据库的增删改程序比较深恶痛绝，觉得比较俗。
不甘于平静的生活，决定跳槽去淘金，新去的公司使用Lotus，在这个公司持续了短暂的两个月的通宵奋战。对Lotus学得也算小有心得。
(回头想想，如果没有工作前几年的知识积累和对技术的狂热，我或许永远也走不到现在这条路。) 对技术的狂热兴趣和爱好，不仅对于架构师，而且对于想做好任何工作的人都是必要的，只有对真正感兴趣的工作，方能做得出类拔萃。
转眼间风气云涌，.COM泡沫正起，BS开始大行其道，试用期没有结束就辞职开始了短暂的创业经历。头是个为了搞个程序可以几天不合眼的人。他认准了BS结构和J2EE，带着我们追逐J2EE之梦，那时是2000年初。
不过这次是完全不用Lotus，改为使用Java了，从学校时候使用VB，到工作后用Unix下C，新的公司用Lotus，现在又完全不用Lotus改用Java了。从学校时候使用VB，到工作后用Unix下C，新的公司用Lotus，每样在周边环境中都能成为佼佼者。有一段时间也是比较浮躁，寻思刨根究底每样都学明白又有什么用？书到看时方去学就行了。这种心态前前后后持续了半年，其间虽然还熬夜，却是都打游戏了。一段时间下来，做J2EE的应用心里还是没有一点底，募然回首，发觉这一段时间收获空空如也。
在头的指导下，对自己做了反思和重新定位，其时架构师的概念在国内开始比较热了，于是我对给自己树立了一个目标，做架构师。目标树立起来后，回顾工作两年来的情况，分析和目标的差距，朝着目标一步步前进。下面是当时的一些反思和体会：
补充基础理论知识。IT的技术发展是非常快的，新技术层出不穷，但是各种技术之间很多原理是一样的，是相通的，重要的是要把原理搞通。笔者所在的学校以管理严格、学生基础扎实、踏实勤奋而著称。但在大学的时候毕竟由于缺乏实践对理论的认识不到位，工作以后回过头来看看老书，发觉有更深刻的认识和丰厚的收获。
扩宽知识面。当时知识面还是太窄，当时对于网络，对于存储，对于大小型机，大于大型数据库几乎都没有深入的接触和使用。对于构建一个全新大型的基于J2EE的企业应用系统来说，架构师需要熟悉数据库技术、操作系统技术、存储、网络技术，J2EE体系架构，MVC框架，Java程序语言，还需要熟悉一到两个应用服务器、一到两门大型数据库。
架构师需要具备扎实全面的技术，掌握广泛的开发技能，超离于程序语言之上，熟悉多种系统架构，有丰富的开发经验，能选择并设计合理的方案。
学习尽可能多的领域知识。软件架构师可细分为应用架构师和技术架构师，应用架构是软件本身作为一个应用而存在的结构，技术架构是使应用能够运转的支撑架构。就像软件是为社会为生活服务一样，技术架构是服务于应用架构的。因此，要做架构师，不能只喜欢纯技术，还要学习尽可能多的领域知识。
要深入、深入到本质里面去，绝对不能浮躁。不光要了解表象，还必须了解隐藏在表象里面的本质。架构师不只是使用者，更多的是建造者，创新者，每一个决定都可能会影响几十个开发人员和成百上千的使用者，因此必须深入熟悉技术的本质，了解原理，才能灵活运用，不可能临时抱佛脚，现学现卖。
（我后来曾见过一些立志做J2EE架构师的程序员，不但不愿意深入学习Java虚拟机规范，对于API也只是一知半解。问其理由，答曰，犯不着搞明白，到用的时候查查API就行了。天哪，到用的时候查查API就行了，如果你是一个摩天大楼的建筑师，到盖高楼的时候现查查各种建材的参数规格指标就能盖起大楼来了么？就能把水、电、梁、管、消防等搭配得合情合理么？想想看，我们做的架构可能也会影响大批设计师和程序员，影响大批使用的用户，岂是现查API就能行的？）
浮躁只会让人一事无成。曾见过一些人，写了两月程序，就嫌写程序低级要去做设计，刚写了两月设计，就嫌设计低级，就要去搞需求分析，刚搞了两天分析，又觉得搞技术没前(钱)途，就要去搞管理或者搞市场。也见过一些人，搞了三月嫌工资低，跳一下涨点工资，再搞三月又跳跳涨点工资。跳来跳去，开始还能往“上”跳， 到后面是只能往被赶着往下跳了。
加强交流和沟通。曾经闷头苦学，希望能学得很牛牛，把什么都研究透了，然后可以教徒弟，可以带出一批人来。在这过程中总是碰到一些槛，虽不至于灰心丧气，但也挺郁闷。头告诉说不要指望一个人都干完了，再厉害也不可能把啥都搞明白了，一方面要形成有一个学习的气氛，大家都很厉害，水涨才能船高，另外一方面要加强和业界尖端人士的交流，共同提高。
关于交流和沟通，古语中提的文人相轻，感觉现在是国人相轻，市场和技术人员相轻，公司间的技术人员之间相轻，殊不知，家里如何横没用，我们应该瞄准的是国外的大厂商，超越他们才是我们中国软件同行的目标。
前两天去建材市场买装修的材料，每家店主都回告诉你这个价高是因为使用了进口材料，那个价低是因为使用了国产的。让人感觉非常的不爽。
要创新，树立正确的学习能力观。当时感觉头说得没错，需要加强交流沟通，自己距离目标差的太远，周边没法寄希望能有人带着做，于是甚至都想到跳槽赔着钱当学徒工都行。头告诉我做好自力更生的准备，国内当时就是欠缺好的架构师，干得好的大多都搞管理去了，剩下没搞管理的不见得碰得到，就算碰到了不见得肯带你，就算肯带你不见得真就比我厉害。我相信他绝对没有贬低同行的意思，只是为了激励我罢。
学习能力对于一个搞IT的人来说非常重要，如果没有很强的学习能力，很难快速适应技术变化的能力。
（我后来碰到不少新员工，因为基本都是从大学毕业的人，学习接收新东西的能力都挺快，但是成就迥然有别。有的人，也具有强烈的好奇心，但为了学习而学习，敝帚自珍，不愿意应用到开发和工作中去，这种人，学到一定程度就很难再提高，学习能力只能算是不及格。
笔者后来在浪潮软件烟草事业部开始做基于J2EE的应用的时候，及时将以前学到的新知识和技术运用到开发中去，从而确立了楼上企业应用框架在浪潮软件的地位。)
在那一年只做了一个物流管理系统一个单，基于J2EE的单子，一切都是从头做，单子额不大内容却不少。虽然最后顺利完成，却因为广泛使用了应用服务器提供商提供的一个不成熟的扩展包而吃尽了苦头。虽说架构师不纠缠于细节，但是忽略了细节却可能造成严重的后果。对于7X24小时系统，一个细节不处理好，就会造成停机和严重的损失。细节就是追求完美，架构师既要有好的大局观，也不能忽略细节，要求我们不仅对原理搞明白，很多时候必须对具体技术实现有透彻的了解。
基于J2EE的BS应用毕竟市场还小，加上其它一些原因，在2001年上半年，公司倒闭员工整体并入浪潮软件成为了浪潮软件的烟草事业部，同时带进浪潮的还有一个J2EE的Framework，楼上Web应用框架1.0。
倚靠浪潮的市场优势和品牌优势，依靠楼上架构的卓越品质和快速二次开发 的能力。浪潮软件在烟草业行业占有率连续几年排名第一。而楼上系列产品也以Web应用框架1.0为基础，发展到今天的包含Web应用框架、工作流平台、商业服务平台、业务规则引擎等的楼上企业应用框架3.0。
楼上企业应用框架也已在除烟草外的通讯、卫生、政务、税务等行业全面开花。依赖楼上企业应用框架构建的在多个行业属于首例全省大型集中式企业Web应用。
在使用楼上企业应用框架构建Web应用中，也有一些经验教训。
在最初的程序中程序员把太多的东西都放到内存session之中，我看见了这个问题并提出来以后数据量大可能会存在问题，但是不少人都认为已经写了不少了改的话返工太多，决定以后再改吧，我屈服了没有继续抗争。但是事实证明我们大家都错了，我们后来有了更大范围的返工，造成不少宕机。架构师应该意志坚强，既不偏执，也不轻易屈服。
客户有时候会提出一些超过条件所能承受的要求，比如说不愿意新建一个OLAP库，要在很繁忙的OLTP库上做复杂的报表查询。如果满足客户的要求，其结果是最后性能达不到要求，影响实时操作的使用。或者即使把性能优化到能满足客户的要求，却付出非常高的代价，最后客户和我们都得不偿失。这时候需要我们要不卑不亢，和客户沟通，说服客户采用更好的技术方案，架构师不仅要和客户沟通，还要和项目经理沟通，和程序员、测试人员沟通。
架构师要对系统的功能负责，对系统的成熟度负责，对系统的成本负责，架构自软件始而始，自软件终而终。架构师需要参与拟定项目的各种标准和规范，要指导大家，要和低层设计人员探讨一些难点的设计问题，他不仅仅是一个技术高手，还要充当技术的领导者，因此，学习一些软件工程的知识和提高领导力是绝对有必要的。
在项目组中，架构师是一个角色，不一定就是一个人，可能是一个小组。
架构师虽然不要忽略细节，也要警惕过分追求完美，架构师学会放弃，在系统的功能、成熟度、成本中取得平衡，从客户的角度和开发者的角度来考虑问题。特别是要警惕技术情结，一味追求最新的不成熟的技术，对于难以完成的功能，需要暂时舍弃，不可能一下造成最完美的系统。
架构是一门科学，更是一门艺术，触类旁通，除了掌握深厚的技术知识以外，要尽可能多的掌握领域知识。
成为架构师，没有速成的办法，唯有实践+努力。
周恒
常和好友孙向晖探讨软件开发之道，他把我作为架构师推荐到程序员杂志，提笔良久却不敢下笔。虽然多年来一直负责开发浪潮软件的企业应用架构，却总觉软件架构师在软件行业中是一神圣的称号，所以不敢随便妄称架构师。
本文叙述了笔者工作以来的历程，穿插谈谈工作以来的一些关于架构师的体会。
尚在大学时候，非常崇拜那些技术天才，特别对求伯君前辈等以一己之力编写著名软件的前辈豪杰等佩服得五体 投地，期望有一天也能像他们那样成为大侠。无论黑天白夜，挥斥键盘程序人生，累了可以游戏中十步杀一人，何等自由与潇洒？
毕业后到公司，有了机器，抱床被子到办公室，静躺着躲过12点钟保安手电的扫射检查，就可以在里面通宵奋战了。两个月时间,也终于把自己打造成气质癫狂、头发蓬乱、脸色苍白、双眼通红、键盘敲得满屋响，具备技术高手的一切外表特征的狂人了。和大多数新工作的程序员一样，那时是比较喜欢搞纯技术的工作，隔壁办公室还有另外一位气质癫狂的战友，和我一样喜欢键盘敲得满屋响，闲暇时候常聊些技术话题，也都对写数据库的增删改程序比较深恶痛绝，觉得比较俗。
不甘于平静的生活，决定跳槽去淘金，新去的公司使用Lotus，在这个公司持续了短暂的两个月的通宵奋战。对Lotus学得也算小有心得。
(回头想想，如果没有工作前几年的知识积累和对技术的狂热，我或许永远也走不到现在这条路。) 对技术的狂热兴趣和爱好，不仅对于架构师，而且对于想做好任何工作的人都是必要的，只有对真正感兴趣的工作，方能做得出类拔萃。
转眼间风气云涌，.COM泡沫正起，BS开始大行其道，试用期没有结束就辞职开始了短暂的创业经历。头是个为了搞个程序可以几天不合眼的人。他认准了BS结构和J2EE，带着我们追逐J2EE之梦，那时是2000年初。
不过这次是完全不用Lotus，改为使用Java了，从学校时候使用VB，到工作后用Unix下C，新的公司用Lotus，现在又完全不用Lotus改用Java了。从学校时候使用VB，到工作后用Unix下C，新的公司用Lotus，每样在周边环境中都能成为佼佼者。有一段时间也是比较浮躁，寻思刨根究底每样都学明白又有什么用？书到看时方去学就行了。这种心态前前后后持续了半年，其间虽然还熬夜，却是都打游戏了。一段时间下来，做J2EE的应用心里还是没有一点底，募然回首，发觉这一段时间收获空空如也。
在头的指导下，对自己做了反思和重新定位，其时架构师的概念在国内开始比较热了，于是我对给自己树立了一个目标，做架构师。目标树立起来后，回顾工作两年来的情况，分析和目标的差距，朝着目标一步步前进。下面是当时的一些反思和体会：
补充基础理论知识。IT的技术发展是非常快的，新技术层出不穷，但是各种技术之间很多原理是一样的，是相通的，重要的是要把原理搞通。笔者所在的学校以管理严格、学生基础扎实、踏实勤奋而著称。但在大学的时候毕竟由于缺乏实践对理论的认识不到位，工作以后回过头来看看老书，发觉有更深刻的认识和丰厚的收获。
扩宽知识面。当时知识面还是太窄，当时对于网络，对于存储，对于大小型机，大于大型数据库几乎都没有深入的接触和使用。对于构建一个全新大型的基于J2EE的企业应用系统来说，架构师需要熟悉数据库技术、操作系统技术、存储、网络技术，J2EE体系架构，MVC框架，Java程序语言，还需要熟悉一到两个应用服务器、一到两门大型数据库。
架构师需要具备扎实全面的技术，掌握广泛的开发技能，超离于程序语言之上，熟悉多种系统架构，有丰富的开发经验，能选择并设计合理的方案。
学习尽可能多的领域知识。软件架构师可细分为应用架构师和技术架构师，应用架构是软件本身作为一个应用而存在的结构，技术架构是使应用能够运转的支撑架构。就像软件是为社会为生活服务一样，技术架构是服务于应用架构的。因此，要做架构师，不能只喜欢纯技术，还要学习尽可能多的领域知识。
要深入、深入到本质里面去，绝对不能浮躁。不光要了解表象，还必须了解隐藏在表象里面的本质。架构师不只是使用者，更多的是建造者，创新者，每一个决定都可能会影响几十个开发人员和成百上千的使用者，因此必须深入熟悉技术的本质，了解原理，才能灵活运用，不可能临时抱佛脚，现学现卖。
（我后来曾见过一些立志做J2EE架构师的程序员，不但不愿意深入学习Java虚拟机规范，对于API也只是一知半解。问其理由，答曰，犯不着搞明白，到用的时候查查API就行了。天哪，到用的时候查查API就行了，如果你是一个摩天大楼的建筑师，到盖高楼的时候现查查各种建材的参数规格指标就能盖起大楼来了么？就能把水、电、梁、管、消防等搭配得合情合理么？想想看，我们做的架构可能也会影响大批设计师和程序员，影响大批使用的用户，岂是现查API就能行的？）
浮躁只会让人一事无成。曾见过一些人，写了两月程序，就嫌写程序低级要去做设计，刚写了两月设计，就嫌设计低级，就要去搞需求分析，刚搞了两天分析，又觉得搞技术没前(钱)途，就要去搞管理或者搞市场。也见过一些人，搞了三月嫌工资低，跳一下涨点工资，再搞三月又跳跳涨点工资。跳来跳去，开始还能往“上”跳， 到后面是只能往被赶着往下跳了。
加强交流和沟通。曾经闷头苦学，希望能学得很牛牛，把什么都研究透了，然后可以教徒弟，可以带出一批人来。在这过程中总是碰到一些槛，虽不至于灰心丧气，但也挺郁闷。头告诉说不要指望一个人都干完了，再厉害也不可能把啥都搞明白了，一方面要形成有一个学习的气氛，大家都很厉害，水涨才能船高，另外一方面要加强和业界尖端人士的交流，共同提高。
关于交流和沟通，古语中提的文人相轻，感觉现在是国人相轻，市场和技术人员相轻，公司间的技术人员之间相轻，殊不知，家里如何横没用，我们应该瞄准的是国外的大厂商，超越他们才是我们中国软件同行的目标。
前两天去建材市场买装修的材料，每家店主都回告诉你这个价高是因为使用了进口材料，那个价低是因为使用了国产的。让人感觉非常的不爽。
要创新，树立正确的学习能力观。当时感觉头说得没错，需要加强交流沟通，自己距离目标差的太远，周边没法寄希望能有人带着做，于是甚至都想到跳槽赔着钱当学徒工都行。头告诉我做好自力更生的准备，国内当时就是欠缺好的架构师，干得好的大多都搞管理去了，剩下没搞管理的不见得碰得到，就算碰到了不见得肯带你，就算肯带你不见得真就比我厉害。我相信他绝对没有贬低同行的意思，只是为了激励我罢。
学习能力对于一个搞IT的人来说非常重要，如果没有很强的学习能力，很难快速适应技术变化的能力。
（我后来碰到不少新员工，因为基本都是从大学毕业的人，学习接收新东西的能力都挺快，但是成就迥然有别。有的人，也具有强烈的好奇心，但为了学习而学习，敝帚自珍，不愿意应用到开发和工作中去，这种人，学到一定程度就很难再提高，学习能力只能算是不及格。
笔者后来在浪潮软件烟草事业部开始做基于J2EE的应用的时候，及时将以前学到的新知识和技术运用到开发中去，从而确立了楼上企业应用框架在浪潮软件的地位。)
在那一年只做了一个物流管理系统一个单，基于J2EE的单子，一切都是从头做，单子额不大内容却不少。虽然最后顺利完成，却因为广泛使用了应用服务器提供商提供的一个不成熟的扩展包而吃尽了苦头。虽说架构师不纠缠于细节，但是忽略了细节却可能造成严重的后果。对于7X24小时系统，一个细节不处理好，就会造成停机和严重的损失。细节就是追求完美，架构师既要有好的大局观，也不能忽略细节，要求我们不仅对原理搞明白，很多时候必须对具体技术实现有透彻的了解。
基于J2EE的BS应用毕竟市场还小，加上其它一些原因，在2001年上半年，公司倒闭员工整体并入浪潮软件成为了浪潮软件的烟草事业部，同时带进浪潮的还有一个J2EE的Framework，楼上Web应用框架1.0。
倚靠浪潮的市场优势和品牌优势，依靠楼上架构的卓越品质和快速二次开发 的能力。浪潮软件在烟草业行业占有率连续几年排名第一。而楼上系列产品也以Web应用框架1.0为基础，发展到今天的包含Web应用框架、工作流平台、商业服务平台、业务规则引擎等的楼上企业应用框架3.0。
楼上企业应用框架也已在除烟草外的通讯、卫生、政务、税务等行业全面开花。依赖楼上企业应用框架构建的在多个行业属于首例全省大型集中式企业Web应用。
在使用楼上企业应用框架构建Web应用中，也有一些经验教训。
在最初的程序中程序员把太多的东西都放到内存session之中，我看见了这个问题并提出来以后数据量大可能会存在问题，但是不少人都认为已经写了不少了改的话返工太多，决定以后再改吧，我屈服了没有继续抗争。但是事实证明我们大家都错了，我们后来有了更大范围的返工，造成不少宕机。架构师应该意志坚强，既不偏执，也不轻易屈服。
客户有时候会提出一些超过条件所能承受的要求，比如说不愿意新建一个OLAP库，要在很繁忙的OLTP库上做复杂的报表查询。如果满足客户的要求，其结果是最后性能达不到要求，影响实时操作的使用。或者即使把性能优化到能满足客户的要求，却付出非常高的代价，最后客户和我们都得不偿失。这时候需要我们要不卑不亢，和客户沟通，说服客户采用更好的技术方案，架构师不仅要和客户沟通，还要和项目经理沟通，和程序员、测试人员沟通。
架构师要对系统的功能负责，对系统的成熟度负责，对系统的成本负责，架构自软件始而始，自软件终而终。架构师需要参与拟定项目的各种标准和规范，要指导大家，要和低层设计人员探讨一些难点的设计问题，他不仅仅是一个技术高手，还要充当技术的领导者，因此，学习一些软件工程的知识和提高领导力是绝对有必要的。
在项目组中，架构师是一个角色，不一定就是一个人，可能是一个小组。
架构师虽然不要忽略细节，也要警惕过分追求完美，架构师学会放弃，在系统的功能、成熟度、成本中取得平衡，从客户的角度和开发者的角度来考虑问题。特别是要警惕技术情结，一味追求最新的不成熟的技术，对于难以完成的功能，需要暂时舍弃，不可能一下造成最完美的系统。
架构是一门科学，更是一门艺术，触类旁通，除了掌握深厚的技术知识以外，要尽可能多的掌握领域知识。
成为架构师，没有速成的办法，唯有实践+努力。