第三次博客作业JSF

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并没有直接的联系，长方法实现功能多，规格就一个，短方法往往功能不出错反而被扣规格。

体会

能认真改的地方就改一改，虽然改了也可能会被扣，但不改更可能。

多次继承的作业一定要仔细修订先前错误，否则越后期越难改。

希望能把代码写的越来越优秀，不被测试者喷格式垃圾（又没办法反驳毕竟他说的没啥不对）。