第三次博客作业JSF

JSF规格化设计发展史以及为什么得到人们重视

查阅了n多资料但是仍然没找到。

第三次博客作业JSF

就说一些jsf的优势吧。

优势:    (1)UI组件

    (2)事件驱动模式

    (3)用户界面到业务逻辑的直接映射

    (4)程序员和网页设计的人员分工

    (5)请求处理生命周期的多阶段划分

    (6)伴随工具而生存

    (7)全面的用户自定义支持

    (8)Web开发的官方标准之一

参考链接:JSF的优势及未来发展趋势

被报告的规格bug

JSF bug  原因
REQUIRES:1

没有判断参数条件

MODIFIES:0

EFFECTS:3

没有使用布尔表达式

不完整

判断“==”写成“=”

第十次作业中无论方法代码长短(即代码行数无参考价值),都出现了这些bug,长代码仍然难以改正

第十一次作业修正了除了run方法以外的其余短方法,但是任然漏了==号

规格bu*生原因

短方法开始并没有重视,长方法由于代码上百行(例如整个taxi的状态转移算法都实现在了run里面),jsf无从下手,只好写个描述了出租车运行状态转移变化。

jsf参考文档并未理解精髓,总想着使用自然语言水过去,但是测试者不放过。

列举前置后置条件不好的写法

(1)自然语言,虽然开始算对但是用自然语言确实不太好(但是分高啊)

(2)对于多种可以合并的判断条件没有合并,条件过长

(3)表示模糊,泛泛带过

(4)格式不一致

(5)对于带锁多线程额外规格未处理

修改方案:一定要使用布尔表达式,不要再笼统盖过,方法写短,判断条件可合并简化则简化。清楚自己实现的到底是什么功能,仔细写规格。对于带锁多线程加上新规格。

分析

方法 功能bug 规格bug
main 3 1
scanftxt 4 1
一些短方法 0 2

个人认为规格bug和功能bug并没有直接的联系,长方法实现功能多,规格就一个,短方法往往功能不出错反而被扣规格。

体会

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

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

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

上一篇:java之程序流程控制


下一篇:Java基础之流程控制