软件架构

软件架构

1. 项目中的每个子系统都有自己的方向，把子系统的决策方向合起来再加入它们之间的关联调用就构成了一个完整的架构，即每个系统、模块、组件都是软件系统架构中的一部分。

架构图

1. 在架构设计中，为了能够更好的整理，思考，描述，表达我们的想法；为了让自己和大家能够更加系统的认识架构的意图，结构以及各个子系统。
2. 架构图不关心实现的细节，只关心整体的解决方案。架构图要做到从宏观的角度能看明白整个项目的布局，能够让人一目了然。

架构图的分类

1. UML对象关系图 - 描述数据类之间的关系
2. 部署图 - 描述需要用到的服务器及起到的作用，以及它们之间的相互关系
3. 时序图 - 描述系统程序调用的次序和流程

评估架构的好坏

以下各方面都很重要，木桶效应里最短的那块木板才是产品好坏的关键。

承载力

1. 多个程序员共同工作，彼此工作的模块耦合度是否能够保持原来的设计要求，共同开发时效率是否够高。
2. 当代码行数扩展到100万行时是否依然能够有序且规范地运行。
3. 对于服务器来说，当前架构能够承受多少DU（Daily User）？
4. 对于客户端来说，当前架构能显示多少UI元素，可渲染多少模型？

如果承载力太低，访问量一上来就卡在加载页面，大家就不会有耐心来看你的产品了。运营和宣传部门在导入流量时，效果就会大打折扣。这对于单机游戏来说也是成立的，加载时间过长，玩家就不会乐意等待。

可扩展性

1. 可扩展性的关键在于，是否能够在添加了新的子系统后不影响或者尽可能少的影响其他子系统的运作。如果添加了新的子系统，其他的系统要全部重构，那就是灾难。

易用性

1. 如果强行推动不好用的系统，团队之间就会加深矛盾，会十分影响开发效率。
2. 易用性决定了架构的整体开发效率，程序员容易上手，子系统容易对接，开发效率就高。
3. 易用性的关键是耦合低，只需要关注很少的一部分，就可以完成自己的那份工作

可伸缩性

1. 当需要的承载量没有这么大时，可以不使用不需要的功能，化繁为简，只启用需要的部分功能，这样就可以随时简化开发流程。
2. 从客户端的角度，伸缩力体现在是否既能适应大型项目上，如上百人协同开发一个复杂系统，也能适应小项目上，如1～3人小团队的快速开发环境，即小成本小作品的快速迭代。

容错性以及错误的感知力

1. 容错性体现在能够防止在使用过程中出现错误而彻底不能使用，需要有备份方案。
2. 从客户端角度看，容错性包括当程序发生错误时，是否同样能够继续保持运行而不崩溃；当这个页面程序出错时，是否依然能够运行其他程序而不闪退或崩溃。
3. 对错误的感知力体现在能够让开发人员及时得知问题已经发生，以及问题的位置，最好能够通过Email等方式自动通知维护者，并记录错误信息。

软件架构的思维方式

1. 牢记我们看到的世界都是模块化的组合方式。
2. 必须具备以下三种抽象能力。

1. 分层思维

1. 分层是我们应对和管理复杂性的基本思维武器。
2. 把整个系统划分成若干个层次，每一层专注解决某个领域的问题，并向上提供服务。
3. 几个分层案例
   • Linux操作系统
   • TCP/IP[[计算机网络|互联网]]协议栈

2. 分治思维

1. 当遇到那些从未处理过的问题，或者特别复杂以至于超出你能力范围的问题时，把它先进行分解、拆分、解剖、撕裂。把大问题分层小问题，再分而治之。小问题解决了，大问题也就解决了。
2. 项目发布流程设计Demo

3. 演化思维

1. 你的架构应该可以不断进化，学习了新的知识就把它加进来。
2. 在软件系统的整个生命周期中，前期的设计占三分，后期的演化占七分。
3. 实际工作中，我们对层级和模块逐个攻破的同时，也进入了架构演化模式。在一开始构建的架构中，某部分的设计可能并不十分合适，在后面的工作中我们需要对其逐步修复、完善甚至替换，这些都是演化的重要步骤。

Unity项目框架组成

1. 网络框架

2. UI框架

3. 数据框架

4. 核心战斗框架

5. AI框架….

   

怎样培养架构设计思维

1. 良好的架构设计思维的培养，离不开工作中大量高质量项目的实战锻炼，以及平时的学习、思考和总结。
2. 架构师在关注技术、开发应用的同时，需要定期梳理自己的架构设计思维，积累的时间长了，看待世界事物的方式会发生根本性的变化，你会发现我们生活的世界，其实也是在抽象、分层、分治和演化的基础上构建起来的。
3. 对抽象、分层、分治和演化掌握的深度和灵活应用的水平，直接决定架构师解决问题域的复杂性和规模大小，是区分普通应用型架构师和平台型/系统型架构师的一个分水岭。
4. 注意架构设计的文档要及时跟进完善，在抽象的过程中，我们需要整理和记录整个过程，以便在今后完善架构 时有途径获得前面在做决策时所考虑的各方面问题。