JSF规格化设计发展史以及为什么得到人们重视
查阅了n多资料但是仍然没找到。
就说一些jsf的优势吧。
优势： （1）UI组件
（2）事件驱动模式
（3）用户界面到业务逻辑的直接映射
（4）程序员和网页设计的人员分工
（5）请求处理生命周期的多阶段划分
（6）伴随工具而生存
（7）全面的用户自定义支持
（8）Web开发的官方标准之一
参考链接：JSF的优势及未来发展趋势
被报告的规格bug
| JSF bug | 原因 |
| REQUIRES：1 |
没有判断参数条件 |
| MODIFIES：0 |
无 |
| EFFECTS：3 |
没有使用布尔表达式 不完整 判断“==”写成“=” |
第十次作业中无论方法代码长短（即代码行数无参考价值），都出现了这些bug,长代码仍然难以改正
第十一次作业修正了除了run方法以外的其余短方法，但是任然漏了==号
规格bug产生原因
短方法开始并没有重视，长方法由于代码上百行（例如整个taxi的状态转移算法都实现在了run里面），jsf无从下手，只好写个描述了出租车运行状态转移变化。
jsf参考文档并未理解精髓，总想着使用自然语言水过去，但是测试者不放过。
列举前置后置条件不好的写法
（1）自然语言，虽然开始算对但是用自然语言确实不太好（但是分高啊）
（2）对于多种可以合并的判断条件没有合并，条件过长
（3）表示模糊，泛泛带过
（4）格式不一致
（5）对于带锁多线程额外规格未处理
修改方案：一定要使用布尔表达式，不要再笼统盖过，方法写短，判断条件可合并简化则简化。清楚自己实现的到底是什么功能，仔细写规格。对于带锁多线程加上新规格。
分析
| 方法 | 功能bug | 规格bug |
| main | 3 | 1 |
| scanftxt | 4 | 1 |
| 一些短方法 | 0 | 2 |
个人认为规格bug和功能bug并没有直接的联系，长方法实现功能多，规格就一个，短方法往往功能不出错反而被扣规格。
体会
能认真改的地方就改一改，虽然改了也可能会被扣，但不改更可能。
多次继承的作业一定要仔细修订先前错误，否则越后期越难改。
希望能把代码写的越来越优秀，不被测试者喷格式垃圾（又没办法反驳毕竟他说的没啥不对）。