技术博客
(1)
发展历史：这个问题我没有找到很近似的答案，但我知道既然能这么问那么规格的发展历史肯定很悠远。可以肯定的是，规格化设计是伴随着计算机软件技术越来越成熟的过程不断完善的，是程序员之间墨守成规的一种写法，在多人团队合作设计中非常有用。
得到重视的原因：设计者先把规格写好，交给开发者，开发者才能根据这个规格来进行代码的构造，这个在系统性很强的工程化开发中应该会很有效率，相当于用一种简洁的语言进行想法的传递。但在这次课程中用处不大，因为开发者和设计者都是一个人。
(2)分析规格bug
|
Bug编号 |
分支树名称 |
位置 |
|
0 |
Overview是否明确抽象对象 |
Request类27行 |
|
1 |
JSF不规范 |
MapReader类30行 |
(3)bug原因
0：手抖忘记写repOk方法了
1: repOK写成了reqOK方法
(4)
前置条件不好的写法
1.@REQUIRES:None 改进：没有前置条件就干脆别写了
2.@REQUIRES:this 改进：this！=null 或者别写
3.@REQUIRES:(A!=null);(B!=null) 改进： 写成&&
4.@REQUIRES: (0<=x1,x2,x3,x4<=100) 改进：分开写呗
5.@REQUIRES: all String args[] 改进：没前置条件就别硬写
后置条件不好的写法
1.@EFFECTS:all+自然语言 改进：全写自然语言
2.@EFFECTS:exceptional _behaviour:XXX 改进：明确产生异常的条件
3.@EFFECTS: his 改进：直接写this
4.@EFFECTS: esult = a 改进： esult == a
5．@EFFECTS:( esult == a)==>(XXX) 改进：反过来写 不能因果倒置
(5)聚焦关系
|
方法名 |
功能bug |
规格bug |
|
ReadMap |
0 |
1 |
|
Request |
0 |
1 |
|
Run(Taxi) |
3 |
0 |
|
FindShortestPath |
1 |
0 |
|
InitCommand |
1 |
0 |
(6)
基本思路
先写方法的规格 在脑袋里构造出一个大致的思路然后再实现。在实现的过程中一步一步再修改规格，对每一种情况做好容错的处理，所以基本上前置条件也不用写太多
感想
规格真的很麻烦 但是他对我们这些程序员来说非常有意义 我最爱写规格了 同时也喜欢仔细看别人写的规格 看看他写的代码是不是规格的正确形式 从中吸取经验教训 再看看能不能给他扣分 这样对于我oo课的成绩也有很大的提高 毕竟规格容易检查 一个还那么多分 比起查功能性bug来讲简直得分效率高得不知道到哪里去了 真开心 简直是一举多得