标签：java 使用 问题 javascript 工作 代码
国内我们对架构师，项目经理，开发经理或者是技术总监这类职业定位普遍不都不清晰，很多的情况是“能者多劳”，一人身兼数职。达尔文的理论在我们的行业是绝对适用的，我从进入这个行业开始我就不甘于成为淘汰者，而我也由心地热爱着这个行业很年前我就立志要成为架构师（当年流行叫：系统分析员 ）这目标进发。回首这10几年的磨练，我总结了一下一名合格的架构师应该具备哪一些方面的能力以及怎么才能得到这些能力
架构师是一个职业，是一种经历了各种磨练与长年开发经验积累出来的。另外我一直认为：不会编码的架构师不是一个好的架构师。我见过很多所谓的架构师完全不懂编码，但总喜欢拿着架构说事。但从严格来说他们并不属于“软件架构师”的范畴，充其量只能算是个“系统架构设计师”，遇到这样的”架构师“我总喜欢说一句话：”Don’t tell me the concepts show me the code!“。
不参与编码并不代表不会编码，如果没有过硬的开发基础，巨量的编码时间积累为基础，在设计软件时一定会忽略非常多的细节，而这将会直接影响到整个项目的成败，试想想当项目经理按照架构师设计的软件蓝图订制开发计划与安排项目资源时由于“蓝图”内存有大量未确定的风险因素，以及由风险触发后所带来的不可预知的结果，最后项目是否能成功 ？
世界上最难的两件事是：将别人口袋的钱放到自己的口袋里面；将自己脑子的想法完整放到别人的脑子里面。
我认为一份成功的设计是 ”能让不同层面的人都能看得懂“。为什么这样说？那么得了解谁需要看设计，又是出于何目的来看设计。
不同的开发方法与开发流程都会有不同的设计文档要求，而受众无非也是上述几种。作为项目/软件的设计者，能清晰地向受众准确地传达自己的设计思路就显得极其重要。这里指表达不是指嘴上的功底，更多的是在工具的掌握能力与文字的表达能力。使用不同的工具表达向不同的受从表达相同的理念，这基实是对架构设计的一种验证，这种沟通与表达能有效地融合不同角度的观点，也能让架构师能更深入地理解自己的设计方向。
要面对如此多的复杂性应该如何来锻炼自己的表达性呢？
正如XP（极端编程）中所说：“世界上唯一不变的就是变化”。拥抱变化、预测变化、控制变化不单纯是优秀开发人员的和项目经理的要求同样也是架构师一种重要的能力。
我的理解 设计中的“变” 就是 “可定制化” 的要求，可定制化程度越高系统/项目的可扩展性就越强。架构师就是需要锻炼的是控制这种变化的范围与程度，“变”是双刃剑，允许过多的变化就会造成“过度设计”，出现一大堆“未来可能使用的功能”；过于封闭则会变得僵化难以适应新的要求。
这里所说的“不变”也只是相对而然，在系统/项目中相对不变的就应该是“核心”或者是“基础框架”，举最简单的例子就是 .net framework 就是其中一者，虽然它会不断发展，增强功能。但其基础核心设计理念与架构也从来没有发生过质的改变。更具体的一点来说“不变”的是规则、用法和基础设计理念。
我认为学习控制变化的最佳方法是多看出色的类库或系统，多问为什么这样做，理解原设计师的想法。经过一定时间的积累，随着对“变化”观察的增多，自然而然会在自已的设计中按设计要求将”变“与”不变“应用得当。
针对架构设计的方法论众多，应该如何选择？我也读过很多的相关书籍，我只选最实用的，这里我推荐几本书。
方法论的实践与应用也需要时间磨合并融会贯通，它们给予我们更多的是理念与意识，一定要避免走进为实践方法论而设计的误区。
成为架构师的路子我相信还有许许多多，我相信相同的是每位架构师都需要通过长时间的学习、实践、思考而也且也拥有一颗热爱软件心。
标签：java 使用 问题 javascript 工作 代码
原文地址：http://www.cnblogs.com/Ray-liang/p/3815657.html
