《敏捷软件开发》读书笔记（4）
气象站系统的实践
-
开始，先分析需求、用例，确定计划。根据具体的需求和非功能性的需求，选取开发语言，准备开始软件设计。
-
软件设计，考虑优先解除对界面的依赖，用OBSERVER模式，创建一个ADAPTER作为观察者，收到数据后去刷新界面。
-
再考虑如何解除对传感器修改的依赖，因为Schedule主要是要耦合不同传感器的触发周期，那就单独把触发周期抽象一个触发器，由传感器实现，告诉Schedule在某个时间唤醒自己即可，这样Schdule就只完成了一件工作，符合SRP原则。
-
考虑如何创建一套独立的API，和现有系统隔离，利用BRIDGE模式把硬件API从现有系统提取出来，把实现和抽象分离。
-
分离这些对象的实现后，创建对象的代码非常繁杂，再利用FACTORY模式把创建过程封装起来，进一步隔离实现类，把相关的实现类放在一起处理。
-
进一步把平台实现类的创建过程封装到工厂类中，只需要替换一行代码，就可以切换到另一个平台。
-
接下来拆分包，对软件的几个部分分别进行发布和分发，把UI从Station解耦出来，由主程序分别初始化。
-
进一步解除UI和具体实现的依赖，把添加监听的部分，抽象出接口类，让UI依赖接口，系统实现接口，进一步解除耦合。
-
在监控之余实现数据持久化和相关策略计算逻辑，还是利用OBSERVER，监听变化和时钟，并且将通用算法分离出去。
-
进一步解除策略和具体持久化实现的耦合，利用PROXY模式，在PROXY里调用持久化，把具体策略封装到另外的类中去调用，使其满足SRP。
-
再利用FACTORY把具体的创建对象封装起来，而如何解决持久化层需要依赖策略层的问题？这里用了一个静态引用来存储工厂类的实现实例。（疑问，由app层，把机制的抽象传进去，不就可以了？）
-
考虑要不要再次利用工厂解除算法策略和代理类之间的依赖？需求认为到这里就足够了。
ETS框架实践
项目过程回顾
在开始就单独创建框架是失败的，试图抛弃真实需求创建一个可重用的框架，是无法满足需求的。作者舍弃了原有的方案，改为了在开发框架的同时，并行开发4个需求，如果在过程中发现相似的部分，只有应用于超过4个需求的代码，才允许出现在框架中。（平台化也是这个思路，只有超过几个业务同时使用的代码，才可作为平台层来构建）最终框架的复用能力，在后期提供了强大的开发效率，并且设计没有被打破，经受住了需求的剧烈变化。
框架设计
-
利用TEMPLETE METHOD模式，把评分的遍历逻辑放到了基类，评分核心差异交给子类处理。
-
利用STATE模式，设计画图界面的命令区和绘图区的交互，接收鼠标和命令区按钮点击事件，转换为事件和设置状态的动作。
-
最后创建了一个TASKMASTER框架，用来管理诸多的任务实现，每个任务都是一个小的FSM完成一组操作。
整个ETS是很大的一个系统，其中用到的策略，做的取舍，都值得在日常工作中学习。
全本总结
- 架构是由需求驱动，在设计的过程中的一切权衡，都是因为需求导致。
- 依赖抽象总是好的，分离逻辑和调用、分离算法和控制，就形成了各种各样的模式。
- 敏捷再敏捷，结尾的小故事和小品，真实的呈现了敏捷开发和交付的实践方式，频繁和需求交流，并且大家都关注与最核心的部分。
来源：CSDN
作者：drumdream
链接：https://blog.csdn.net/drumdream/article/details/103846424