关于系统架构，维基百科给出了一个非常好的定义。 A system architecture is the conceptual model that defines the structure, behavior, and more views of a system.[ (系统架构是概念模型，定义了系统的结构、行为和更多的视图)
- 系统架构是一个概念模型。
- 系统架构定义了系统的结构、行为以及更多的视图。 关于这个定义，这里给出了另外一种解读，供大家参考。
- 静。首先，从静止的角度，描述系统如何组成，以及系统的功能在这些组成部分之间是如何划分的。这就是系统的“结构”。一般要描述的是：系统包含哪些子系统，每个子系统有什么功能。在做这些描述时，应感觉自己是一名导游，带着游客在系统的子系统间参观。
- 动。然后，从动态的角度，描述各子系统之间是如何联动的，它们是如何相互配合完成系统预定的任务或流程的。这就是系统的“行为”。在做这个描述时，应感觉自己是一名电影导演，将系统的各种运行情况通过一个个短片展现出来。
- 细。最后，在以上两种描述的基础上，从不通的角度，更详细的刻画出系统的细节和全貌。这就是“更多的视图”。
好代码的特性：
- 鲁棒(Solid and Robust)
- 高效(Fast)
- 简洁(Maintainable and Simple)
- 简短(Small)
- 可测试(Testable)
- 共享(Re-Usable)
- 可移植(Portable)
- 可观测(Observvable)/可监控(Monitorable)
- 可运维(Operational): 可运维重点关注成本、效率和稳定性三个方面
- 可扩展(Scalable and Extensible)
工程能力的定义： 使用系统化的方法，在保证质量的前提下，更高效率的为客户/用户持续交付有价值的软件或服务的能力。
在《软件开发的201个原则》一书中，将“质量第一”列为全书的第一个原则，可见其重要性。 Edward Yourdon建议，当你被要求加快测试、忽视剩余的少量Bug、在设计或需求达成一致前就开始编码时，要直接说“不”。 开发前期的设计文档、技术评审3天以上100%。代码规范，缺乏认真的代码评审。 降低质量要求，事实上不会降低研发成本，反而会增加整体的研发成本。在研发阶段通过降低质量所“节省”的研发成本，会在软件维护阶段加倍偿还。
在研发前期(需求分析和系统设计)多投入资源，相对于把资源都投入在研发后期(编码、测试等)，其收益更大。
构件在软件领域是指可复用的模块，它可以是被封装的对象类、类树、一些功能模块、软件框架(framework)、软件架构(或体系结构Architectural)、文档、分析件、设计模式(Pattern)。但是，操作集合、过程、函数即使可以复用也不能成为一个构件。
- 有用性(Usefulness):构件必须提供有用的功能。
- 可用性(Usability):构件必须易于理解和使用，可以正常运行。
- 质量(Quality):构件及其变形必须能正确工作，质量好坏与可用性相互补充。
- 适应性(Adaptability):构件应该易于通过参数化等方式再不同环境中进行配置，比较高端一点的复用性，接收外界各种入参，产生不同的结果，健壮性比较高。
- 可移植性(Portability):构件应能在不同的硬件运行平台和软件环境中工作，可移植性比较好，跨平台。
其实就是解决某一类问题的方法论，是生产经验和生活经验中经过抽象和升华提炼出来的核心知识体系。 模式就是一个完整的流程闭环，能够解决一些问题的通用方法(比如资本运作、玩家不同的需求等)，软件中的模式大多源于生活，是人类智慧的结晶。
规划是系统架构中最重要的组成部分，是个人或者组织制定的比较全面长远的发展计划，是对未来整体性、长期性、基本性问题的思考和考量。设计未来整套行动的方案。很早就有规划这个概念了，例如:国家的十一五规划等。当然软件开发也和生活紧密联系，一个大型的系统也需要良好的规划，规划可以说是基石，是系统架构的前提。
系统架构虽然是软件系统的结构，行为，属性的高级抽象，但其根本就是在需求分析的基础行为下，制定技术框架，对需求的技术实现。
- 单一目的
- 对外关系清晰
- 重视资源约束
- 根据需求做决策
- 基于模型思考
无论模块是多么的‘封闭’，都会存在一些无法对之封闭的变化。既然不可能完全封闭，设计人员必须对于他设计的模块应该对哪种变化封闭做出选择。他必须先猜测出最有可能发生的变化种类，然后构造抽象来隔离那些变化
开放-封闭原则是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处，也就是可维护、可扩展、可复用、灵活性好。开发人员应该仅对程序中呈现出频繁变化的那些部分做出抽象，然而，对于应用程序中的每个部分都刻意地进行抽象同样不是一个好主意。拒绝不成熟的抽象和抽象本身一样重要
迪米特法则首先强调的前提是在类的结构设计上，每一个类都应当尽量降低成员的访问权限，也就是说，一个类包装好自己的private状态，不需要让别的类知道的字段或行为就不要公开
我们在程序设计时，类之间的耦合越弱，越有利于复用，一个处在弱耦合的类被修改，不会对有关系的类造成波及。也就是说，信息的隐藏促进了软件的复用。”
- 邮箱 ：[email protected]
- Good Luck!