（转载）中国优秀软件架构师感悟录

转载自：http://news.csdn.net/n/20090306/123867.html

 

我认为，优秀的软件架构师在软件开发行业中占据着很重要的位置。国外优秀的软件都是因为软件架构师开发了一 个扩展性很强的架构才使产品不断完善和升级的。反观中国，一大部分企业比较急功近利，认为界面够漂亮就行了，完全不关心代码的组织和架构。日本这几年也在 注重软件架构上的分析和设计，所以有很多产品和项目外包让中国来做利润最少的部分。我们应该开始有意识地做这方面的事情，培养出一大批中国的优秀软件架构 师。只有这样，中国的软件才有希望！
来自业界的声音
       什么是架构师呢？架构师是软件行业中一种新兴职业或者是角色，他要主导系统全局的分析设计和实施、负责软件构架和关键技术决策。其工作职责是在一个软件项 目开发过程中，将客户的需求转化为规范的开发计划及文本，并制定这个项目的总体架构，指导整个开发团队完成这个计划。架构师的主要任务不是从事具体的软件 程序的编写，而是从事更高层次的开发构架工作。他必须对开发技术非常了解，并且需要有良好的组织管理能力。可以这样说，一个架构师工作的好坏决定了整个软 件开发项目的成败。
在中国，有多少人算得上是“软件架构师”呢？或许很多人抱着不屑一顾的看法，认为只有盖茨才算得上是架构师，其他人都不过是朝自己的脸上贴金。不过，我们却不同意这种说法，因为毕竟软件架构师只是一种角色，就像只承认米开朗基罗是建筑师一样，都是极端的。
       中国软件这么多年的发展中，已经有一批出色的程序员跳出了程序的限制，正在从系统架构和全局设计的角度创建大型软件甚至软件平台，有些人虽然担任着管理职 位，但在技术上他们仍然无愧于软件架构师的称谓。而程序员通过了解这些架构师的经验和体会，也能够朝更高的方向发展。也希望通过他们的感悟，尽可能吸引更 多的人走上软件架构师的职位。

梁永昌趋势科技研究部和软件系统架构部副总裁
       主持产品与项目：1990年开发出LANProtect For Novell Netware Server第一版。此产品为业界第一个为Netware Server设计的反病毒产品，领先其它品牌达九个月。从1995年至今，担任趋势科技反病毒引擎(VSAPI)软件架构师。这是因为在进行 LANProect的产品设计时，遇到当时反病毒引擎和其它产品在源代码上无法共享的问题，当时反病毒引擎越来越复杂，各个产品使用的反病毒引擎功能不尽 相同，造成客服相当困扰。因此决定将反病毒引擎独立出来成为一个共享的模块，至今趋势科技所有反病毒产品都使用此引擎模块。
       感悟：软件架构师在工作的范围和责任上与盖房子的建筑师很类似，必须知道他要盖的是什么房子，有多少预算，施工期有多长，现在要的是两层楼，但以后会不会 要加盖上去，厕所要几个，厨房在哪里，哪里要设门，哪儿要开窗，梁柱要多粗，要用什么材料？因为，盖四合院和十层大楼是不一样的。
同样，软件架构师必须知道他要设计的是什么软件，将被什么样的客户在什么样的环境下使用，可使用系统资源限制是多少，兼容性要求高不高，安全要求是什么等 级，会不会有下一个版本，下一个版本又将增加什么功能，模块和模块之间的关系是什么，每一个不同的考虑都会影响设计，软件架构师就是要在考虑过种种因素后 决定软件的架构和使用技术。
       大家都知道，要在老四合院顶上加盖十层楼，全部推倒重来可能是唯一的可行方案。同样，软件因架构不好造成的问题或限制是很难改善的，有时甚至必须重新设 计，这将会是一项耗时费力的投资，与其到时再来一次，不如现在就把架构做好。就像各式各样的建材一样，现在的软件市场上有太多现成的模块可供软件架构师选 用，但这也造成一个问题：很多软件架构师只知有哪些模块可用，却不知模块内部做了什么工作。这种知其然不知其所以然的软件架构师随着Internet盛行 而兴起，这种软件架构师现在到处可见，架过Web Server，写过CGI/VBS，再连上个Database，简历上就自称软件架构师，多层式网络架构(Multi-Tiers Web Serivce Architecture)谈起来头头是道，讨论起细节却让人摇头。现成的模块可以用，也应该用，但最重要的是要知道模块的功能和限制是什么，为什么会有 这样的限制，为什么用这个模块而不用另一个。
       其实商业软件架构师最大的挑战还是在折中的拿捏上。人力总是不足，时间永远不够，面对现实状况的压力，当完美设计(每个人都如此自认)无法如愿被全盘采用 时，讨论(或争吵)就不可避免，效能可不可以让步，安全等级能不能降低些，哪些项目可以改变，哪些又该坚持到底，这些都是要做出的决定，而且更重要的是要 能让大家充分了解你做此坚持是出自何种考虑。
       软件架构师的工作伙伴大都也是技术人员，就像自古文人相轻一样，技术人员彼此的尊敬只会建立在技术能力的优越性上，软件架构师必须要有深厚的技术底子和宽 广的业界信息，再加上一点口才和亲和的态度，这才容易获得其它工程师的认可和尊敬，也才不会你画你的十层楼，他盖他的四合院。

廖恒毅佳软公司董事长
       主持产品与项目：曾负责中文之星2.0的开发，佳软企业管理软件的架构设计，拼音加加等一系列软件的架构设计。
       感悟：软件设计是一项极具挑战性的工作。尽管软件设计人员为世界上无数的人提供了工作的便利，让大家的工作越来越自动化，软件设计者自己的工作却远没有见 到能够自动化的可能性。无数的人为了找到一套软件设计的理论苦苦追寻，到目前为止， 很难看到有什么实质性的进展。当银弹总是不出现的时候，也许大家都应该想想，其实银弹也许根本就不存在。
       大家都听说过这个寓言故事。一个数学家跟国王下国际象棋，国王问他如果赢了，要什么样的奖励。数学家说，很简单，你在第一个棋盘格放一粒米，第二个棋盘格 放两粒米，然后一直翻倍下去，把整个64个棋盘格放满就好了。国王很痛快地答应了数学家的要求。但是，当国王真的给数学家奖励的时候，才发现这是不能兑现 的，因为没有任何一个国家，即便是加上全世界的粮食也不够。
       讲这个大家耳熟能详的故事，其实是想谈谈我对软件架构师的认识。真正的软件架构师所面临问题的复杂度，其实与这个故事很相像。大家都在凭直觉理解软件的复 杂度。而且都想得很浅， 1，2，4，8…… 多简单的问题，即便是想到第十级，也不过就1024。再往下想一些，也还是大家能够理解的数字。而人们凭着直觉，也就顶多想到第20格。第20格的数字还 没有超出人们的理解范围的。真正的难题在第40格以后，很少有人能够理解第40格以后是什么了。而第60格的难度呢，根本就不是第40格能够比拟的。如果 我们大家都仅仅用直觉的加法来理解问题的话，最后，我们会进入不可解的范畴。人类真正聪明的地方就在于发明了对数，用对数的方法解决了对这个问题的理解。 即便是第64格，也不难理解了，不过就是2的64次方。
当然，软件复杂度的问题其实比这个问题更加难解，所以我们到现在为止，还没有找到软件中的这个对数算法。但是，基于目前软件界的认知，我们多少有了一些解 决方案：对象编程，组件模型，多层结构……，已经为软件设计提供现实可行的方法。问题是，这些概念理解起来也非常不容易。大家都说着同样的词汇，却有可能 干着完全不同的事情，所以才会有误解，才会有争执。软件架构师是一个靠无数经验积累的结果。尤其是优秀的软件架构师，跟所有别的能够成为“师”的职业一 样，在对自己的行业有了基本的了解之后，在自己不断成长的过程中，并没有一定的套路的。靠的是领悟力，靠的是对这个现实世界哲学性的思考。当用哲学的眼光 来观察这个世界的时候，就离一个优秀的软件架构师不远了。
       一个优秀的软件架构师，如果他愿意学的话，同样应该能够做出很香的饭菜来，因为软件架构师和厨师有相通的地方。大家以为如何?师者，通也。

何健金算盘CTO，首席架构设计师。
       主持产品与项目：4年管理软件架构设计经验，曾经先后规划和设计了金算盘多年的主流产品。1997年，自主设计和开发了金算盘电子表格，以当时最先进的 VC开发出的产品的功能、界面、特性比当时的Excel更具有本地化特色，作为财务管理软件的报表系统，在当年的全国财务软件评测中报表获得了第一。 2002年，在多年的管理软件架构开发的背景下，经过长期的探索和思考，形成了平台的构想。并采用了先进J2EE技术，成功开发出了金算盘VP平台。
       感悟：架构师是客户需求和开发者之间的桥梁。在软件行业中，一般提到的架构师是技术架构师，而实际上产品架构包括业务架构和技术架构，只有技术架构和业务架构紧密结合才有可能真正创造出一个好的系统。
       产品架构是现代应用开发领域最重要的课题。在这个课题里，没有终结答案可寻，惟有恒久的问题存在。在纷繁的问题中，最重要和最“真”的问题是产品竞争力问 题。除此之外，软件架构的目的还包括满足既有客户需求和提高开发效率，并且要求产品架构能更好地支持商业流程，有利于企业业务集成。金算盘VPS系列产品 就是以此为指导进行架构的产品。
       我在做了多年的产品架构后，对这项工作也有一些自己的感触：
       首先，架构是技术。按照摩尔定律的推断，软件业的技术也同样在日新月异地发生着变化，我们已经见证了开发工具越来越短的生命周期。从VB到 ASP.Net，从C到Java，无论采用什么新的语言，都体现了不同时期的架构要求。架构已经跨越了简单的过程模型，对象－时间模型，而今更多的是谈论 MDA，模型的快速建立，使得软件能够快速适应用户变化成为了可能。而采用先进的技术，使得软件能够更加深度地满足客户需求。技术本身的发展是无止境的， 如何使得软件能够适配新技术，成为一种更为重要的技术。采用各种模式的设计、逻辑分层、降低技术耦合使得技术的融合成为可能，也成为一项高难度的技术。
       其次，架构是艺术。产品架构师需要捕捉技术和业务这个完整拼图里的某一块或某个脉络作为设计的线索。架构师永远不是先知，而是“存在的探索者”，产品架构 的结果要在产品开发周期完毕时才能被印证。产品架构既要反映对技术的需求，使得架构满足对技术的适配，对发布模式能够提供多样化支持，能够满足性能的要 求，还能够满足对业务管理的需要，要适应目标应用的业务特性。这样的架构，才是为应用服务的软件架构，而不仅仅是一个简单的可重用的技术工具。更重要的是 它具有软件的管理基因，正如平台能够得到大量客户认可，其中最主要的就是它为客户提供了技术平台、管理工具、基础业务，并使得它们有机地高效地结合在一 起。如同流淌的艺术作品一样，充满了生机和互动。
       同时，架构是质量。好的架构可以使得软件产品成为一棵常青树。在和国内外软件产品对比分析的时候，经常有这样的感悟，其实好多国外的软件产品，采用的技术 并不是最先进的，但是它具有非常优秀的质量，产品稳定可靠，同时还具有良好的技术适配能力，从而使得产品适应技术变化的能力非常强。这样，投资人对软件的 投资价值能够得到最充分的体现，这是国内职业经理人非常值得关注和学习的。

陈小群互信互通信息技术有限公司研发主管
       主持产品与项目：全球眼数字视频监控系统。系统组成包括客户端、中心服务平台，包括：接入服务器、前端视频服务器、分发服务器、存储服务器、全球眼应用服务器等。系统规模为17个开发人员用时8个月，源代码行数大约15万。
       感悟：软件架构对软件系统来说就象建筑结构对建筑物、人骨架对人一样，是其它成分的基础，是满足功能和性能需求的关键，因此，软件架构师对软件研发项目的成败具有决定性的作用。
软件架构师并不像他的名字所提示的那样仅仅负责架构的设计，通常他的工作还包括，作为技术专家负责协助开发部门、技术支持部门、产品规划部门等各方解决技 术问题。因此，他的管理和沟通能力是同样重要的。其它主要的知识和技能还包括分析和解决问题的能力、将需求转化为设计的能力、对系统未来发展的预见能力 等。
       一个优秀的程序员会是一个优秀的软件架构师吗？不一定。对于一个复杂的软件系统来说，架构设计通常都不是一个人就可以完成的任务，需要一组具有不同知识的 工程师协作完成，在这个过程中，架构师要做大量的解释、说服、协调、总结、归纳、妥协等工作。一个没有担任过负责人的程序员缺乏这方面的经验。
同时，国内一种普遍的现象是，大量缺乏编程经验的博士、硕士、项目经理负责软件架构设计，并声称不需要学习编程也能搞好软件架构设计。计算机科学是一门实 验的、技能性的学科，许多概念必须在编程实践中体会，技能更是必须要操练才能提高。很难想象一个不懂编程的人会理解设计模式，而不懂设计模式的人会是一个 优秀的软件架构师！一个看了很多棋谱但从没有实战过的人声称自己是布局高手，你会信吗？
全球眼数字视频监控系统是一个大型分布式系统，它的开发涉及到分布式系统、网络编程、网络协议、视频、音频、控制、系统管理、数据库、内容管理、Web编 程等许多方面的知识。作为软件架构师，在技术方面感受最深刻的是对化繁为简，以及分析和解决问题能力的要求。化繁为简就是将一个复杂的解决方案分解为一系 列简单的小方案，不仅可以提高开发效率，而且还可以提高系统的稳定性。对于不断出现的技术问题，架构师应该能够迅速判断其难度、重要程度，自己解决不了的 话，可以有效利用其它资源解决。
       在非技术方面，沟通能力特别重要，你要将你的设计思想传达给开发团队，这件事情已经很不容易了，更困难的是，你还要传达给技术支持人员，甚至一些非技术人员。有的时候，你还必须妥协，采用一些其他成员支持的、也许不是最好的解决方案，以保持团队的士气。
       总之，管理、沟通、经验、分析问题和解决问题的能力是一个软件架构师必备的素质。对于一些所有工程师都应该具有的素质，比如，工作热情、责任心、迎接挑战的勇气等，就不用多说了。

许式伟金山软件WPS产品架构师
       参与产品与项目：曾参与WPS Office之电子表格项目和WPS Office 2002项目。从2002年至今，参与WPS V6项目。成立框架项目，负责KFC（金山基础代码库）、数据层、IO体系（XML标准等）以及Shell（用户界面）等公共组件的研发。

       感悟：今年是金山软件创建十六周年，十六年来金山的每一款成功软件都凝聚了历代软件架构师的心血。每一个金山人都会对自己职业有着深刻认识。
从性格角度来讲，软件构架师需要心思细腻而严谨；从职业特征来看，软件构架师要充分理解和尊重软件产品的需求。由需求引导设计而不是相反。因此，需要特别 强调产品需求的重要性。记得GOF有这样一句话：“设计应该支持变化－－获得最大限度复用的关键在于对新需求和已有需求发生变化时的预见性，要求你的系统 设计要能够相应地改进”。每个程序员都希望能够写出最好的程序，并使自己的程序更能适应变化。但事实表明，程序能力尤其是框架设计能力并不是天生的，而是 取决于程序构架师对需求的理解程度。如果在不了解系统需求的前提下，就开始进行设计，那么即使是天才，也不能设计出完美的框架。
从另外一方面讲，软件构架师的设计只能应付可预测的变化，而构架师本身的技术积累和对需求的理解程度，往往会决定所设计的框架对需求变化的应变能力。大多 数的设计人员都趋向于追求完美，大多对“开闭法则” （OCP：Open Close Principle，注：Software Entities should be open for extension,yet close for modificaiton.:程序应该可扩展但又不可修改）非常认同。而这是一个理想状态，但又不可太过，一味地让系统应付位置的变化，会让自己套上一个 无形的枷锁，更为正确的做法是：让自己知道的尽可能多，当设计新版本WPS Office V6的整体框架时，通常会参考Microsoft Office和旧版本的WPS Offfice，有时甚至会看PDF对同一功能的支持情况，对同类产品的研究和比较，有助于很好地设计新产品的程序框架。
       此外，作为软件构架师，一定要善于听取和接纳不同的意见，能够包容新的思想，愿意了解最新的技术和想法。优秀的软件工程师，他应该具有创新的理念和兼容并 包的胸怀，比如：C#、AOP等。尽管我最喜欢C++的自由，但并不排斥去了解Java、C#等语言对其的改进，很多新的事物，会让我获得共鸣与灵感。
正如上面所讲，软件工程师需要更强的技术积累和更缜密的思维，以及对需求的深刻理解、兼容并包的创新意识和胸怀，软件构架师的职责顾名思义，从事的主要工 作职责就是设计软件产品的程序构架，也就是要，对他最终设计的结果－－软件产品的程序框架负责。可操作性和系统的应变能力是软件构架师的主要职责和工作重 点。
       我虽不是计算机专业，却是一位计算机狂热爱好者，对C语言有着深刻的领悟，被同学们戏称“C狂”，曾独立开发、与同学合作开发软件。我对于感兴趣的东西， 总是去探索它内在的实质性内容。从小就酷爱数学的我，在推理的严谨上对自己要求非常高。我相信一个观念：严谨绝对不是创造的对立面，而是创造性思维的必备 条件。

王栋 盛世龙吟数字科技
       主持产品与项目：主持产品与项目：负责国家疾病预防控制中心的“非典型肺炎个案调查报告管理系统”、“国家疾病报告管理信息系统”、“SARS早期预警监 测试点项目”。国家质量产品认证中心的“认证人员管理系统”等。其中采用Apex Portal Server（24人/月）兼容于JSR-168的portal实现，采用一些成熟的开放框架，使用轻量级设计开发理念，加速开发速度缩短开发周期。

王栋  盛世龙吟数字科技
       感悟：软件架构师是团队中的一员，和其他项目成员没有什么区别，只不过承担的职责要大些，因为毕竟架构设计师所作的工作比较重要。架构设计师的具体工作是为系统设计架构，做技术的决策。而国内对于各种角色分工不明确，通常架构师都有项目管理的职责。
一个成功的架构设计师一定是不仅精通设计工作而且精通实现工作的。缺乏了设计的实践，就缺少了对系统整体的把握；缺乏了实现的实践，则缺少了对系统中某些 重要技术点的全面了解。在和团队成员的交流当中，特别是讲述自己的设计思想时，设计图固然重要，但设计图只能提供一个概念模型，真正的设计还是需要用源代 码体现。为了更好的设计和实现还要掌握各种工具和类库的使用，因为架构设计师有时还是技术咨询顾问。
       在系统设计和技术决策时，最难做到的就是平衡和取舍。在规定的时间内，团队内部人员的技术水平和状态、技术的成熟稳定度、技术实现的难易程度等因素都会影 响系统架构的最终实现。比如去年四月底—正是SARS在北京闹得最凶的时候，我们接到了国家疾病预防控制中心的《非典型肺炎个案调查报告管理系统》的开发 任务，由于国家疾病控制中心没有一套基于互联网的疾病申报系统，给这种突发性的传染性疾病申报工作带来一些困难。全部基于传真和电话的申报信息必须经过人 工处理才能形成报告上报，而面对神秘的SARS，申报的内容在不断的调整，上报的流程也在不断地更改，如果我们仍然按照通常的应用程序开发方法，可能很快 就能完成这样简单的数据提交工作，但是如果任何地方稍有改变，程序开发人员必须在现场完成程序更改。由于当时的特殊情况，我们的开发团队也不可能保持特别 大的规模，而时间要求又极其苛刻——一周之内系统要测试上线。经过权衡，认为必须满足可实时动态定制申报内容以及定制的查询统计，我们承担着巨大的压力， 最后决定采用简化的模型实现系统，用项目成员最熟悉的技术和概念，完成保证系统运行的最小功能集合。
       对于一个系统或产品，还需要有不断改善它的耐心，有时还需要推翻重新实现的勇气。上边提到的项目第一阶段，在疯狂的加班加点中基本完成了。不过，由于时间 仓促系统还是有改进和提高的余地。在接下来的几个月时间内，我们做的就是不断对这个系统细化，深化，修改，调整。这时候，其他相关项目也要启动了，启用我 们的核心引擎后，经过很短时间的定制，都分别上线运行了，充分体现了原有模型的设计重用性和系统的可扩充性。但精益求精，针对新的需求，我对原有的一些设 计缺陷有了新的认识，界面不够灵活、流程不能定义、结构稍显混乱，等等。
       随着又一个项目，所有上次积累下来想修改的东西都有了机会重新实现，这是多么美好的感觉。国家质量认证中心的业务系统，有更多表单要填写，有更多的复杂流 程要实现，有更多的组织机构和角色要定义，需要更灵活的表现形式和配置功能。以前的系统引擎就不能满足了，就决定使用更新的结构、更新的工具甚至是更新的 过程来实现。这回我们做到了每一个工作流可以用户自定义，每一个工作流节点中的表单用户可以自定义，每一个查询都可以自定义。随着时间推移，这套系统也在 不断演进中。
作为软件架构师，学习的能力和态度、敏锐的观察能力是非常重要的。必须通过各种途径学习和观察。对于目前国内的应用状况和互联网应用的不断深入，在不断的 学习和观察中我觉得不管在哪些方面都需要整合，不管是企业内部的各种信息孤岛还是互联网上的各种应用。如何去整合资源，为最终用户服务，这个问题让我自然 想到了Portal，这将是我们公司下一个重要发展方向。面对Portal世界中纷繁的技术，下一波的学习和实践就要启动了。
       一个软件架构师，要勤于学习、观察、思考，决不放弃对最底层实现技术的掌握同时需要把握好系统框架的平衡，学会正确的取舍，并且要有耐心和勇气面对自己的设计，不断进行改进甚至重新实现。

周恒  浪潮软件技术研究中心
       主持产品与项目：开发了Web应用框架，配套开发包，树立了企业应用框架在浪潮软件的地位。这一产品也从以Web应用框架1.0为基础，发展到今天的包含 Web应用框架、工作流平台、商业服务平台、业务规则引擎等的企业应用框架3.0。这一企业应用框架也已在除烟草外的通讯、卫生、政务、税务等行业全面开 花。
       感悟：回顾工作两年来的情况，分析和目标的差距，朝着目标一步步前进，谈谈我的反思和体会：
补充基础理论知识。IT的技术发展是非常快的，新技术层出不穷，但是各种技术之间很多原理是一样的，是相通的，重要的是要把原理搞通。
       扩宽知识面。最初，我的知识面还是太窄，当时对于网络、存储、大小型机、大型数据库几乎都没有深入的接触和使用。对于构建一个全新大型的基于J2EE的企 业应用系统来说，架构师需要熟悉数据库技术、操作系统技术、存储、网络技术，J2EE体系架构，MVC框架，Java程序语言，还需要熟悉一到两个应用服 务器、一到两门大型数据库。
       架构师需要具备扎实全面的技术，掌握广泛的开发技能，超离于程序语言之上，熟悉多种系统架构，有丰富的开发经验，能选择并设计合理的方案。
       要深入。深入到本质里面去，绝对不能浮躁。不光要了解表象，还必须了解隐藏在表象里面的本质。架构师不只是使用者，更多的是建造者，创新者，每一个决定都 可能会影响几十个开发人员和成百上千的使用者，因此必须深入熟悉技术的本质，了解原理，才能灵活运用，不可能临时抱佛脚，现学现卖。
浮躁只会让人一事无成。曾见过一些人，写了两月程序，就嫌写程序低级要去做设计，刚写了两月设计，就嫌设计低级，就要去搞需求分析，刚搞了两天分析，又觉 得搞技术没前(钱)途，就要去搞管理或者搞市场。也见过一些人，搞了三月嫌工资低，跳一下涨点工资，再搞三月又跳跳涨点工资。跳来跳去，开始还能往“上” 跳， 到后面只能被赶着往下跳了。
       加强交流和沟通。曾经闷头苦学，希望能学得很牛，把什么都研究透了，然后可以教徒弟，可以带出一批人来。在这个过程中总是碰到一些槛，虽不至于灰心丧气， 但也挺郁闷。头告诉说不要指望一个人都干完了，再厉害也不可能把啥都搞明白，一方面要形成一个学习的气氛，大家都很厉害，水涨才能船高，另外一方面要加强 和业界尖端人士的交流，共同提高。
       学习能力对于一个搞IT的人来说非常重要，如果没有很强的学 习能力，很难快速适应技术变化的能力。
有一年只做了一个物流管理系统一个单，基于J2EE的单子，一切都是从头做，单子额不大内容却不少。虽然最后顺利完成，却因为广泛使用了应用服务器提供商 提供的一个不成熟的扩展包而吃尽了苦头。虽说架构师不纠缠于细节，但是忽略了细节却可能造成严重的后果。对于7X24小时系统，一个细节不处理好，就会造 成停机和严重的损失。细节就是追求完美，架构师既要有好的大局观，也不能忽略细节，要求我们不仅对原理搞明白，很多时候必须对具体技术实现有透彻的了解。
       架构师要对系统的功能负责，对系统的成熟度负责，对系统的成本负责，架构自软件始而始，自软件终而终。架构师需要参与拟定项目的各种标准和规范，要指导大 家，要和低层设计人员探讨一些难点的设计问题，他不仅仅是一个技术高手，还要充当技术的领导者，因此，学习一些软件工程的知识和提高领导力是绝对有必要 的。
       在项目组中，架构师是一个角色，不一定就是一个人，可能是一个小组。
       架构师虽然不要忽略细节，也要警惕过分追求完美，架构师学会放弃，在系统的功能、成熟度、成本中取得平衡，从客户的角度和开发者的角度来考虑问题。特别是 要警惕技术情结，不能一味追求最新的不成熟的技术，对于难以完成的功能，也需要暂时舍弃。不可能一下造成最完美的系统，

袁德俊 软件工程师 自由职业
       主持产品与项目：1997年金山游侠开发成功，一直从事系统编程多年。目前，自主开发的C语言规范的脚本语言“NGNc”具有高聚合低偶合的系统设计。NGNc从体系结构和应用层级都与JAVA如出一辙，绝非模仿，而是从需求中来。
       感悟：自从电脑出现在我的视野，能延伸我的头脑是我对计算机的最直接感受。而从事软件编程更给我无穷的力量和冲动，探索、挑战、驾御是我从一个个不眠之夜 的开发中获得的最大乐趣。起初只是简单的重复着编译Sample，添加个别功能，以为语言就是计算机的全部。随着系统编程的深入，渐渐我的思维习惯转变 了，操作系统的代码跟踪，给了我更大的空间去探索，就象进入了一个幽暗神秘的海洋，漫漫地与现在的各种概念越来越远，有时候同朋友们沟通都缺乏了共同的关 注焦点。

       开发NGNc完全是个偶然的机会。 一 直以来，用VC的IDE环境开发项目，并组织和管理项目需要的文件，尽管VC的功能很强大，但在项目后期，每每都是因为修改个别的数据，而重新编译整个项 目，很麻烦。起初，通过设计系统的数据文件格式，将数据文件搬移出项目，将引擎和数据分离，只在修改数据的时候，用数据编辑器或简单文本进行描述。编制数 据编辑器虽然可以避免规范数据输入等优点，但额外工作产生了：文本描述成为我们主要的目标。
       最初文本描述方法简单，比如Window的Ini文件管理模式。随着文本文件格式的逐步复杂，文本文件到特定数据格式的转换工具越来越想向C语言转变。这就是NGNc的第一个产生的契机。我们叫它“DataOut”，顾名思义就是将数据拿出来的意思。
       项目开发的越多，项目后期对控制逻辑和规则描述的需求也逐步呈现出来。仅仅DataOut已经不能满足我们的需要，起初同文本数据描述一样，只是简单的规则罗列，但随着功能的发展，支持简单的类C语言的规则书写方式被支持了。
发展到现在NGNc已经完全成为了真正的C语言，并拥有自己的虚拟机，IDE调试环境，NGNbios的UI支持库，它还将会拥有很多很多。随着我对NGNc的驾御，我的视野宽广了，可以想象在它的支持下的应用会更加开枝数叶。
       另外说明一下：NGN是“Engine”的音，NGNc是我对它的期望，不只驱动应用，更可以驱动我的梦想，就如同每个程序员在深夜里完成一段代码后的成就感一样。
我对“软件架构师”的理解是，它只是众多软件行业内的一个分工，无论它的高度如何，需要多么资深的背景，多少年头的开发经验，他只是一个岗位，就如同其他 岗位一样，他需要思考他这个层面的问题。任何一个岗位都可以说是一个架构师，如同：人体、器官、组织、细胞，都是个相对封闭的系统，都异常的精密，只是它 们都有它们各自的责任范围。
       软件架构师如果是软件工程师的能力体现，他应该具备从宏观到微观的全部知识，并在他的头脑中运转着整个行业甚至世界的模型，他可以通过自己头脑的精密模 拟，实现对任何问题的把握，无论是宏观还是微观。我们之所以需要这样的人，就是因为我们的电脑无法完成如此复杂的计算，即使用巨大的知识库阵列也无法达到 大脑的快速处理速度，有时候，架构师的一个感觉就可以左右整个行业甚至未来。
具备这样高度的人是值得人们崇拜的！

后 记
       软件架构师可细分为应用架构师和技术架构师，应用架构是软件本身作为一个应用而存在的结构，技术架构是使应用能够运转的支撑架构。就像软件是为社会为生活服务一样，技术架构是服务于应用架构的。
有不少新员工，因为基本是从大学毕业的人，学习接收新东西的能力都挺快，但是成就迥然有别。有的人，也具有强烈的好奇心，但为了学习而学习，敝帚自珍，不愿意应用到开发和工作中去，这种人，学到一定程度就很难再提高，学习能力只能算是不及格。
       而且，还有一些立志做J2EE架构师的程序员，不但不愿意深入学习Java虚拟机规范，对于API也只是一知半解。问其理由，答曰，犯不着搞明白，到用的 时候查查API就行了。天哪，到用的时候查查API就行了，如果你是一个摩天大楼的建筑师，到盖高楼的时候现查查各种建材的参数规格指标就能盖起大楼来了 么？就能把水、电、梁、管、消防等搭配得合情合理么？想想看，我们做的架构可能也会影响大批设计师和程序员，影响大批使用的用户，岂是现查API就能行 的？
       因此，我们可以说：架构是一门科学，更是一门艺术，触类旁通，除了掌握深厚的技术知识以外，要尽可能多地掌握领域知识。成为架构师，没有速成的办法，唯有实践+努力。