小菜鸡儿的第三次OO博客

规格化设计历史

　　规格化设计的历史目前网上的资料并很少，百度谷歌必应也表示无能为力......

　　在这里结合现实状况讲一讲本身对程序规格化的理解，首先代码规格化对代码的影响是间接的，或许它不能让你代码里面的bug直接消失，或许它也不能让电梯之间不相互阻塞，可是它能让OO实验拿到更多分啊//笑。玩笑归玩笑，下面具体分析一下规格化设计（JSF为例）的做用：

• 在代码实现过程当中，人们每每不能从一开始对整个项目的每一个细节都面面俱到地思考一遍，规格化设计在开发初期能够将项目中的细节隐去，工程师只须要考虑类or包须要完成的功能便可，只用在JSF的effecs写几行功能影响岂不是美滋滋。
• 其次在代码具体实现过程当中，Modifies和Requires有助于减小bug的产生。在项目初期定下的JSF能保证程序猿们在乱七八糟的需求修改下不忘初心，在一次又一次的指导书修改中不忘这个类到底是要完成怎样的历史使命，明确了每一个变量的用途、每一个方法的使用目的，时时提醒程序猿们不要犯一些低级错误。
• 而在企业项目中，代码的规格化尤其重要，一个项目大多都是由一个团队来完成，若是没有统一的代码规范，那么每一个人的代码一定会风格迥异。且不说会存在多我的同时开发同一模块的状况，即便是分工十分明晰的，等到要整合代码的时候也有够头疼的了。大多数状况下，并不是程序中有复杂的算法或是复杂的逻辑，而是去读别人的代码实在是一件痛苦的事情。统一的风格使得代码可读性大大提升了，人们看到任何一段代码都会以为异常熟悉。显然的，规格化的代码在团队的合做开发中是很是有益并且必要的。

---

 

规格bug分析

　　本身写的代码规格基本上属于“你的代码真的很烂”级别，博主懒癌晚期，每次观测点的JSF属于随缘被挂状态。下面来分析一下这些垃圾代码，强迫症大佬谨慎食用：

/**@ REQUIRES: AllNode!=NULL;
* taxi!=NULL;
* loc= int[2];
* des= int[2];

严格地说Requires里面要对各个变量进行详细地规定，要是能与与repOK一致的话是最吼的：

/** @ REQUIRES: AllNode!=NULL;
* taxi!=NULL;
* (loc!=NULL) && (loc.size==2) && (All int i=1;i<=2;)==>(loc[i]>=0 && loc[i]<80);
* (des!=NULL) && (des.size==2) && (All int i=1;i<=2;)==>(des[i]>=0 && des[i]<80);

　　这几回做业在书写JSF规格时，更像是一种亡羊补牢的过程，首先要求咱们具体实现一次代码，再向代码添加JSF，其实与规格化设计略有相悖，另外我认为课程组可能有一点点低估JSF的完成难度，一个优秀的后补JSF须要程序猿阅读本身都快忘了的一坨屎，读完后还须要将代码抽象出通常性的逻辑。以目前北航计算机系大部分同窗的编程风格来讲，数百行的类基本上比比皆是，数百行的方法也是大有人写，将三位行数的代码抽象出effects可不是一个简单的过程，而与此同时还要完成复杂的流量红绿灯设计以及基于gayhub的操做系统，这确实有一点点难了。不过在这几回公测中，我有幸抽到了一份JSF尚可的代码：

/**
 * @REQUIRES:m!=null;
 * @MODIFIES:\this.situation;
 * \this.isCalled;
 * \this.curTime;
 * @EFFECTS:normal_behavior:
 * 出租车行驶，\this.situation按照出租车的行驶状况不断变化；\this.isCalled在出租车成功接到单子时变为true；接单结束后变成false；
 * exception_behavior(InterruptedException e):
 * System.out.println("Oops," + this.toString() + " seems to have some problem.");
 */
　　若是没有记错的话天然语言描述依然是在容许范围以内的，固然就算不容许，我认为依然不该凭此扣分，毕竟从复杂的代码中抽象出effects仍是一个工程量很大的任务。

---

Bug分析
　　

	功能bug	规格bug	是否相关
第九次做业	0	0	否
第十次做业	3	5	否
第十一次做业	0	0	否

 

 　　在最近三次的做业中，第九次做业和第十一次做业没有被互测出bug，第十次做业的问题主要集中在：1.出租车并未直接右转；2.出租车在直行时并未按照红绿灯行驶；3.出租车在派单过程当中并未按照最短路径原则。首先第三个bug是由第一二个bug形成的，毕竟未正确按红绿灯行驶会形成流量决策一定失败，前两个bug的主要问题是在派单函数中并未作到修改出租车的方向。在个人红绿灯体系中，用1，2，3，4四个数字表示绝对方向，分别对应东北西南，而出租车选择一个绝对方向行驶后应当在下一个红绿灯路口前实现转换，如：出租车A在第一个路口决定往北走，当它抵达第二个路口时，它的驶来方向应该是南边，所以形成了红绿灯判别不正确。规格bug主要集中在对出租车的多态实现时，全部的get&set方法没有写JSF，瞬间被挂满~

 

---

心得体会
　　程序是让人看的，是要分享给队友或者老师，甚至是任何陌生的人共享交流。或许你的算法复杂度能作到o(1)，或许你的代码可拓展性很强，可是这些都比不上一群与你一块儿开发项目的程序猿，一群能读懂并指出你规格化代码bug的人。或许在这学期的面向对象课程中JSF是一个很烦人的存在，可是规格化程序设计的重要性是毋庸置疑的。