关于系统架构，维基百科给出了一个非常好的定义。

A system architecture is the conceptual model that defines the structure, behavior, and more views of a system.[

(系统架构是概念模型，定义了系统的结构、行为和更多的视图)

* 系统架构是一个概念模型。

* 系统架构定义了系统的结构、行为以及更多的视图。

关于这个定义，这里给出了另外一种解读，供大家参考。

* 静。首先，从静止的角度，描述系统如何组成，以及系统的功能在这些组成部分之间是如何划分的。这就是系统的“结构”。一般要描述的是：系统包含哪些子系统，每个子系统有什么功能。在做这些描述时，应感觉自己是一名导游，带着游客在系统的子系统间参观。

* 动。然后，从动态的角度，描述各子系统之间是如何联动的，它们是如何相互配合完成系统预定的任务或流程的。这就是系统的“行为”。在做这个描述时，应感觉自己是一名电影导演，将系统的各种运行情况通过一个个短片展现出来。

* 细。最后，在以上两种描述的基础上，从不通的角度，更详细的刻画出系统的细节和全貌。这就是“更多的视图”。

好代码的特性：

1. 鲁棒(Solid and Robust)

2. 高效(Fast)

3. 简洁(Maintainable and Simple)

4. 简短(Small)

5. 可测试(Testable)

6. 共享(Re-Usable)

7. 可移植(Portable)

8. 可观测(Observvable)/可监控(Monitorable)

9. 可运维(Operational): 可运维重点关注成本、效率和稳定性三个方面

10. 可扩展(Scalable and Extensible)

工程能力的定义：

使用系统化的方法，在保证质量的前提下，更高效率的为客户/用户持续交付有价值的软件或服务的能力。

在《软件开发的201个原则》一书中，将“质量第一”列为全书的第一个原则，可见其重要性。

Edward Yourdon建议，当你被要求加快测试、忽视剩余的少量Bug、在设计或需求达成一致前就开始编码时，要直接说“不”。

开发前期的设计文档、技术评审3天以上100%。代码规范，缺乏认真的代码评审。

降低质量要求，事实上不会降低研发成本，反而会增加整体的研发成本。在研发阶段通过降低质量所“节省”的研发成本，会在软件维护阶段加倍偿还。

在研发前期(需求分析和系统设计)多投入资源，相对于把资源都投入在研发后期(编码、测试等)，其收益更大。

* 单一目的

* 对外关系清晰

* 重视资源约束

* 根据需求做决策

* 基于模型思考

无论模块是多么的‘封闭’，都会存在一些无法对之封闭的变化。既然不可能完全封闭，设计人员必须对于他设计的模块应该对哪种变化封闭做出选择。他必须先猜测出最有可能发生的变化种类，然后构造抽象来隔离那些变化

开放-封闭原则是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处，也就是可维护、可扩展、可复用、灵活性好。开发人员应该仅对程序中呈现出频繁变化的那些部分做出抽象，然而，对于应用程序中的每个部分都刻意地进行抽象同样不是一个好主意。拒绝不成熟的抽象和抽象本身一样重要

迪米特法则首先强调的前提是在类的结构设计上，每一个类都应当尽量降低成员的访问权限，也就是说，一个类包装好自己的private状态，不需要让别的类知道的字段或行为就不要公开

我们在程序设计时，类之间的耦合越弱，越有利于复用，一个处在弱耦合的类被修改，不会对有关系的类造成波及。也就是说，信息的隐藏促进了软件的复用。”