目录
- 宏观上的“系统架构”
- 系统架构图（举例）
- 微观上的系统设计
- 生产者-消费者 设计图（举例）
- 宏观架构与微观设计的区别
- 孰轻孰重？
- 三种线程
- 泵的作用
- 代码中泵的作用
- 常见泵结构（1）
- 常见泵结构（2）
- 常见泵结构（3）
- 常见泵结构（4）
- 常见泵结构（5）
- 串行处理数据的泵
- 并行处理数据的泵
- 泵对于系统的意义
- 什么是框架？
- 框架的特点
- 框架的作用（1）
- 框架的作用（2）
- “机场资源调度模拟仿真系统”设计草图
- 几个问题
- 问题答案（1）
- 问题答案（2）
- 微观上看机场系统
- PPT下载
- 系统主要功能（需求分析）
- 确定系统最终使用场合
- 系统划分模块
- 各模块间怎样协作
- 每个模块技术模式（C/S(或单机)、B/S、移动app）
- 每个模块采用什么技术开发
- 出系统架构图、相关文档
- 系统框架搭建（编码）、项目组成员培训（指导）
- 系统运行的持续性（动力）
- 系统处理数据的重复性
- 系统的可扩展性（=>框架）
- 系统的容错性
- 系统的通用性（=>框架）
前者：
- 站得高看得远，将重点放在整个系统组成上。几乎不涉及到“编码”；
- 架构者需要熟悉各种技术，了解各种技术优劣以及适用场合；
- 架构者需要丰富的项目经验。
后者：
- 注重代码实现，侧重系统内部实现原理；
- 设计者需要丰富的编码经验；
- 设计者与if/else/while等打交道。
当你为了解决某个具体问题而设计一个系统时，如果做到了：
- 通用性好。不过分依赖其他模块，不限制处理特定业务；
- 容错性高。内部包含一套专门异常处理机制；
- 扩展性强。方便增加新的功能；
- 提供一套专门类库。
这时候，就可以把该系统当作一个框架。它可以用来处理某一类问题。
- 动力性
- 持续性
- 通用性强
- 可扩展性高
- 容错性好
理论上，任何一个框架不做任何改变，直接编译即可运行。
- 整个系统怎样维持一个“持续运转“的状态？
- 服务端怎样能够持续处理客户端的输入？
- 怎样维持地图中各元素的状态？
- 系统时间怎样统一？
- 怎样维护训练脚本状态？
（以上内容为公司第四次交流会内容）