架构师修炼之路

国内我们对架构师，项目经理，开发经理或者是技术总监这类职业定位普遍不都不清晰，很多的情况是“能者多劳”，一人身兼数职。达尔文的理论在我们的行业是绝对适用的，我从进入这个行业开始我就不甘于成为淘汰者，而我也由心地热爱着这个行业很年前我就立志要成为架构师（当年流行叫：系统分析员 ）这目标进发。回首这10几年的磨练，我总结了一下一名合格的架构师应该具备哪一些方面的能力以及怎么才能得到这些能力

编码能力

    架构师是一个职业，是一种经历了各种磨练与长年开发经验积累出来的。另外我一直认为：不会编码的架构师不是一个好的架构师。我见过很多所谓的架构师完全不懂编码，但总喜欢拿着架构说事。但从严格来说他们并不属于“软件架构师”的范畴，充其量只能算是个“系统架构设计师”，遇到这样的”架构师“我总喜欢说一句话：”Don’t tell me the concepts show me the code!“。

    不参与编码并不代表不会编码，如果没有过硬的开发基础，巨量的编码时间积累为基础，在设计软件时一定会忽略非常多的细节，而这将会直接影响到整个项目的成败，试想想当项目经理按照架构师设计的软件蓝图订制开发计划与安排项目资源时由于“蓝图”内存有大量未确定的风险因素，以及由风险触发后所带来的不可预知的结果，最后项目是否能成功 ？

 

• 多看 - 多看别人的代码，从别人的代码中读出软件的架构与设计的设计思路
• 多学 - 掌握各种语言，不要偏执于某一技术阵形，不管java, .net , phyon 还是javascript每种语言都有其优缺点，成为一名语言控，从语言本身学习与理解语言设计者的思想。
• 多做 -  疯狂编码，从时间与实践中去体验与领悟，工多艺熟。
• 勇敢 - 严格要求自己不要写出”发臭“的东西，勇敢地重构！让代码变得优雅，易读充满你的设计思想。

 

表达力

世界上最难的两件事是：将别人口袋的钱放到自己的口袋里面；将自己脑子的想法完整放到别人的脑子里面。

我认为一份成功的设计是 ”能让不同层面的人都能看得懂“。为什么这样说？那么得了解谁需要看设计，又是出于何目的来看设计。

• 销       售 - 从设计中寻找卖点与特色，丰富销售方案和定制预售计划。
• 项目经理 - 根据设计进行时间估算、项目资源准备与工作分解。
• 开       发 - 根据设计要求进行技术准备、开发环境、编写DEMO以及最终编码 。 
• 测       试 - 根据设计划分测试粒度、准备测试环境、定制测试计划 

 

不同的开发方法与开发流程都会有不同的设计文档要求，而受众无非也是上述几种。作为项目/软件的设计者，能清晰地向受众准确地传达自己的设计思路就显得极其重要。这里指表达不是指嘴上的功底，更多的是在工具的掌握能力与文字的表达能力。使用不同的工具表达向不同的受从表达相同的理念，这基实是对架构设计的一种验证，这种沟通与表达能有效地融合不同角度的观点，也能让架构师能更深入地理解自己的设计方向。

 

要面对如此多的复杂性应该如何来锻炼自己的表达性呢？

1. 多与人沟通，多参与头脑风暴
2. 练习用人类语言表达“非人类”的专业知识。一张用铅笔画的框图往往比一个使用专业UML设计工具做出来的设计更容易让人理解。 UML为作架构师基本上是必修课，也是辅助架构师思维的工具，但对于不懂UML的那就是“非人类”的文档，设计是给人看的，别人看不懂再专业再标准化的设计也只能沦为废纸。
3. 培养测试先行的习惯 - 在设计时多写范例与测试，在很大程度上可以减少设计误区和验证被实现的可行性。这样可以在将设计交付给开发、测试后节约大量的沟通时间。

 

拥抱变化

正如XP（极端编程）中所说：“世界上唯一不变的就是变化”。拥抱变化、预测变化、控制变化不单纯是优秀开发人员的和项目经理的要求同样也是架构师一种重要的能力。

“变” 

     我的理解 设计中的“变” 就是 “可定制化” 的要求，可定制化程度越高系统/项目的可扩展性就越强。架构师就是需要锻炼的是控制这种变化的范围与程度，“变”是双刃剑，允许过多的变化就会造成“过度设计”，出现一大堆“未来可能使用的功能”；过于封闭则会变得僵化难以适应新的要求。 

“不变”

这里所说的“不变”也只是相对而然，在系统/项目中相对不变的就应该是“核心”或者是“基础框架”，举最简单的例子就是 .net framework 就是其中一者，虽然它会不断发展，增强功能。但其基础核心设计理念与架构也从来没有发生过质的改变。更具体的一点来说“不变”的是规则、用法和基础设计理念。

 

我认为学习控制变化的最佳方法是多看出色的类库或系统，多问为什么这样做，理解原设计师的想法。经过一定时间的积累，随着对“变化”观察的增多，自然而然会在自已的设计中按设计要求将”变“与”不变“应用得当。

 

方法论 

针对架构设计的方法论众多，应该如何选择？我也读过很多的相关书籍，我只选最实用的，这里我推荐几本书。

• 《设计模式》- 要读懂、活用，我读了10几年每次都可以从中学到不一样的想法,将其应用于架构内可以极大地简化很多复杂的问题。
• 《Java 编程思想》 - 谈面向对象方面最好的其中一本书，提高面向对象的设计能力会有很大帮助
• 《Refactoring》- 重构不单单是一种做法和程序员才关心的事。重构重于意识与思维完全可以用于架构设计 。
• 《eXtreme Programming》- 虽然讨论的是开发方法，但它最能诠释什么是”变化“。

方法论的实践与应用也需要时间磨合并融会贯通，它们给予我们更多的是理念与意识，一定要避免走进为实践方法论而设计的误区。

 

成为架构师的路子我相信还有许许多多，我相信相同的是每位架构师都需要通过长时间的学习、实践、思考而也且也拥有一颗热爱软件心。