程序员必读之软件架构 - Software Architecture for Developers

http://calvin1978.blogcn.com/articles/software-architecture-for-developers.html

架构师应该编码吗？

有些公司认为架构师太宝贵了，不该承担日常编码工作。
有人认为优秀的架构师的重要特征是抽象思维能力，也可以理解为不把时间耗在细节里。
还有一些大型项目通常意味着照看更大的“大局”，有可能你根本没时间写代码。

以上都对。

你不必放弃编码，也不要把大部分时间用于编码

你不应该因为“我是架构师”，就把自己排除在编码之外。
但也必须有足够的时间扮演技术架构师的角色。

1. 参与编写代码

要避免成为PPT架构师， 最好是参与实现与交付的过程，确保架构的交付，了解设计在实现上的问题，演进架构而不是画完框图就交给实现团队从此不管。
同时，缩短与团队的距离，保持对团队的影响力，帮助团队对架构的正确理解，分享自己软件开发的经验。

另外，作为开发团队的一份子，你不需要是开发代码最好的。

2. 构建原型、框架和基础

如果不能参与日常编码，至少尝试在设计时快速构建原型去验证你的概念。
还有为团队编写框架和基础，这也是最磨练与体现编码与设计能力的时刻。

3. 进行代码评审

如果完全没有时间编码，至少参与代码评审，了解发生了什么。

4. 实验并与时俱进

如果完全没有时间在工作时间里编码，在工作之外你往往有更多空间来维持编码技能，从贡献开源项目，到不断尝试最新的语言、框架。

一般来说，一个写代码的软件架构师会更有成效也更快乐。

撇开代码不说，谈谈我对架构的6个冷思考

2、架构是一个建模的过程

对于一个复杂问题，通常会对复杂问题按照能力领域进行分解，其目的是能够找到与现有能力相匹配的映射。这个映射，就是解决方案。它，离不开人的「知识型劳动」，主要分解为三个方面：

1. 对于已知问题的抽象和建模
2. 对于已知能力的抽象和建模
3. 对于解决方案和工具的设计

其中前两个方面，都提到了「建模」。建模本身是对客观事物的一种抽象，客观事物越复杂，那建模的结果变成「盲人摸象」的概率就越高。

然而，「盲人摸象」在IT领域其实不能算是个「贬义词」，因为这个现象十分的常见。究其原因，解决实际问题信息系统，更多程度是面向于「典型」应用场景，而不是「任意」应用场景的。

场景即是对客观事物的认知视角，信息系统做不到、也不需要对一个完整的客观事物进行全面（360°无死角）建模。

举个具体的例子：对于人这个客观事物，银行系统里，可能会关心这个人财务指标，例如「收入」、「支出」和「存款余额」，但在医院的重症监护病房里，可能就会关心这个人的生命指标，例如「血压」、「心跳」。

从例子里可以看出，一个面向具体问题的场景化应用系统，都是对一个客体进行「片面的」场景化建模。

说到底，建模是一种抽象能力，具体的说，是人对客观事物认知结果的理性提炼和总结，不可否认感性的部分太难以刻画和描述。很符合「庄子·天道」中所述：「意之所随者，不可以言传也」。

如果要拿数学语言进行描述「建模的能力」，就是找到一组尽可能少的「特征向量」去表述这个空间，而找这组「特征向量」的能力，就是建模的能力。

3、架构工作的核心是设计

4、架构需要作出一系列非技术选择

架构既然是个解决方案，自然有很多可以自由选择的领域，有很多受限的前提条件。这些外围因素，往往还系统背后的个人、团队、企业的价值观、以及非IT能力有关，这是一个很容易被忽视的点。

与人和团队的关系