规格化设计历史
规格化设计的历史目前网上的资料并不多，百度谷歌必应也表示无能为力......
在这里结合现实情况讲一讲自己对程序规格化的理解，首先代码规格化对代码的影响是间接的，或许它不能让你代码里面的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还是一个工程量很大的任务。
心得体会
程序是让人看的，是要分享给队友或者老师，甚至是任何陌生的人共享交流。或许你的算法复杂度能做到o(1)，或许你的代码可拓展性很强，但是这些都比不上一群与你一起开发项目的程序猿
，一群能读懂并指出你规格化代码bug的人。或许在这学期的面向对象课程中JSF是一个很烦人的存在，但是规格化程序设计的重要性是毋庸置疑的。
好像有点跳，可能接着更......