这个指标报警系统主要用于视屏播放指标的监测，如清晰度，观看人数等。
在我的开发中，将报警系统分解为了以下几个部分： 1、规则配置部分 2、指标获取部分 3、指标判断部分 4、结果处理部分
可以看出虽然这是一个报警系统，但在我划分的部分中却未有提及报警二字，这中间是有一个我思维转变的过程的。
在最开始设计报警系统时，我总有一个先入为主的观念。认为某某指标值若落入报警范围就该产生报警行为，没落入就舍弃了。在随后的开发中，我发现这种观念有两个不便之处。
1) 某某值：实际就是对单一的指标值进行判断，但现实的情况大多是分析一定范围的指标值才会产生是一个合理的报警行为。
2) 落入报警范围与没落入报警范围：这样不利于一个灵活的报警机制，而且实际上只处理了部分数据，没有处理未落入报警范围的数据，不利于将来系统的扩展。
所以为了解决这种情况，
1) 维护一个队列：队列记录了一定范围内的所有指标值，合力判断报警状态。
2) 对数轴划分区间：利用不同的阈值对数轴划分区间，任何指标值过来了，不管它是否该被报警，先判断它属于哪个区间，然后打上这个区间的状态，这样利用队列，逐渐积累指标状态，根据不同的报警策略产生不同的报警状态，进而产生报警行为。将来想选取任意范围的数据报警，找到对应区间的报警状态就好。
可以看到，我在处理指标数据时，第一种思维是：报警目的 --> 分析数据；
第二种思维是：分析数据 --> 报警目的。
就我现在看来，在开发报警系统时，第二种思维是更好的，即：弱化本来目的，忠于数据本身。
2013.12.18 更新
1）面对一个类时，想到的是：输入、环境配置、输出。不要把环境配置当成输出。
2）类和公共函数记得写说明；注意各种东西的命名
3）一定要明白什么东西是属于什么应该知道的的。比如，MonitorState应该是属于程序应该知道的，而不是过多的在数据库中反应，因为是程序在运行这个Monitor，只要它自己最清楚，如果反应在数据库中，无论如何都是经过了程序这一道手才到数据库的。MonitorTime，IsMailed应该属于MonitorConfig应该知道的，与SDAlert无关，SDAlert只记录具体的配置参数，MonitorConfig记录Monito的状态。如果这里想不清楚，很容易就把MonitorTime，IsMailed放到SDAlert里面去。
4）要多考虑异常处理，至少要写个日志什么的吧？
2014.2.1 更新
1）要注意变量命名风格，C#的public属性一般用Pascal命名规则，即每个单词的首字母大写，加下划线的通常是private属性。
2）使用父类进行变量申明，引用子类的实例是多态性的表现
3）将各种属性合成字符串，再将字符串还原成各种属性，然后再使用，这是个很怪异的过程。在面向对象的编程方法中，直接设计对象和属性即可。
4）命名问题和注释问题。各个类都应该有详细注释说明这个类的用处，在整体架构中所处的位置等等。