第三次博客作业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并没有直接的联系,长方法实现功能多,规格就一个,短方法往往功能不出错反而被扣规格。
体会
能认真改的地方就改一改,虽然改了也可能会被扣,但不改更可能。
多次继承的作业一定要仔细修订先前错误,否则越后期越难改。
希望能把代码写的越来越优秀,不被测试者喷格式垃圾(又没办法反驳毕竟他说的没啥不对)。