oo第三次博客

标签：order   read   开发   table   想法   计算机   方法   团队合作   test   

技术博客

(1)

发展历史：这个问题我没有找到很近似的答案，但我知道既然能这么问那么规格的发展历史肯定很悠远。可以肯定的是，规格化设计是伴随着计算机软件技术越来越成熟的过程不断完善的，是程序员之间墨守成规的一种写法，在多人团队合作设计中非常有用。

得到重视的原因：设计者先把规格写好，交给开发者，开发者才能根据这个规格来进行代码的构造，这个在系统性很强的工程化开发中应该会很有效率，相当于用一种简洁的语言进行想法的传递。但在这次课程中用处不大，因为开发者和设计者都是一个人。

(2)分析规格bug

(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:\this  改进：直接写this

4.@EFFECTS:\result = a   改进：\result == a

5．@EFFECTS:(\result == a)==>(XXX)  改进：反过来写 不能因果倒置

(5)聚焦关系

(6)

基本思路

先写方法的规格 在脑袋里构造出一个大致的思路然后再实现。在实现的过程中一步一步再修改规格，对每一种情况做好容错的处理，所以基本上前置条件也不用写太多

感想

规格真的很麻烦 但是他对我们这些程序员来说非常有意义 我最爱写规格了 同时也喜欢仔细看别人写的规格 看看他写的代码是不是规格的正确形式 从中吸取经验教训 再看看能不能给他扣分 这样对于我oo课的成绩也有很大的提高 简直是一举多得。

oo第三次博客

标签：order   read   开发   table   想法   计算机   方法   团队合作   test   

原文地址：https://www.cnblogs.com/coldnight/p/9099770.html