标签：cts 公司 his 文件内容 adf 内容 支持 head 功能性
??随着社会上各公司业务的发展，项目越来越多，越来越大，复杂性也越来越高。查找一个BUG变得越发抓狂；新人熟悉一块代码也变得越发困难。有的时候顺手写下的一行充满坏味道的代码，可能当时不会出现什么影响，而且当事人也十分清楚自己写的东西。但是，当日积月累之后，这种坏代码越来越多，整个项目就变得混乱不堪，牵一发而动全身，各种错误，修复了这影响了那。久而久之，规格化代码就成了不可或缺的一部分，其重要性不亚于代码本身。
??而要解决前面说的这些情况，必须要有一个规范来进行约束。不以规矩不成方圆，而且，这些规范必须也要有比较持续稳定的代码审核机制来支持。所以，当下规格化设计越来越受到人们的重视。
??三次作业下来，总共被挑出1个规格相关bug。这个bug其实跟规格本事关系不大，如下：
\*
*@overview:
*\ ??帮我测试的同学认为这里要写在同一行，而不是三行，理由是课件上是写在同一行的。其实当时的初衷是这样写能够让对面看的时候轻松一些，岂料想被报了一个bug……言归正传，虽然jsf规格方面没有被挑出过多bug，但这并不意味着自己的jsf足够规范。
| 名称 | Before | After |
|---|---|---|
| ??尽量使用布尔表达式?? | ??@REQUIRES：long类型的wait_time?? | ??@REQUIRES:wait_time== long type |
| ?? 过多使用自然语言 ?? | ?? @REQUIRES:int类型的pos_x ?? | ?? pos_x == int type ?? |
| ??缺失?? | ??@REQUIRES:None?? | ??@REQUIRES:sc!=null?? |
| ??考虑当前方法所使用的某个属性的范围?? | ??@REQUIRES：this.state == int type,this.id==int type?? | ??@REQUIRES:0<=id<=99,0<=this.state<=3?? |
| ??构造方法中传入的某些对象型参数应有效?? | ??略?? | ??@REQUIRES：taxi_gui has been initalized?? |
| 名称 | Before | After |
|---|---|---|
| ??布尔表达式?? | ??@EFFECTS:\result为long类型?? | ??@EFFECTS:\result == long type?? |
| ??从未使用谓词逻辑?? | ??以出租车数组的初始化为例?? | ??@EFFECTS：\all car[i].stats;0<=car[i].state<=3?? |
??这几次作业功能性方面一共被挑了三个bug。
??在写每个方法前，都会先确定该方法需要的参数，由此便确定了前置条件；接着，思考该方法的目的，进而确定modifies；最后思考该方法执行后的效果来确定effects。三次作业写下来，不再有前两个月的写代码时那种山一般的感觉；反之，这三次的代码更注重培养对于细节把控的能力，以及对规范化设计思想的理解。
标签：cts 公司 his 文件内容 adf 内容 支持 head 功能性
原文地址：https://www.cnblogs.com/T-shuo/p/9107565.html
