关于规格的前世今生
（的确很难找，因此参考了部分其他同学的调研结果。。）
规格是扎根于形式化的设计方法而产生的
最初的软件形式化方法源于二十世纪五十年代，及软件工程这一概念刚刚开始兴起的时代，对于工程间的协调管理，人们提出采用工程方法来组织、管理软件的开发过程并深入探讨程序和程序开发过程的规律，建立严密的理论。这一结构发展至今，规格已经形成一套完整的逻辑体系并融入软件开发的各个步骤，,从需求分析、功能描述(规约)、(体系结构/算法)设计、编程、测试直至维护。
在二十世纪七十年代，规格产生了第二次分离，这一分离主要是针对于说明和体的分离，并开始出现前后置协调的雏形。这一次的分离使得规格可以更好的区分置换条件，以适应新兴的跨时代面向对象技术。
二十一世纪初期开始，规格基本完善成如今的形式，并更加侧重于基于构件的对象使用和对象实现。应用现有的规格规范，软件可以轻松的实现分布式，跨平台，松耦合的开发需求。
规格的意义
在于规范和协调，减少错误并完成设计和实际代码的衔接。
个人认为在进行程序设计的时候，大多数方法和类的设立是根据逻辑层面而运作的，这些脑中设立的预代码要对应实际的书写并和java的API耦合需要一个形式化的监控以提供安全保障，并且有一个规范作为有效性的检测标准，这就是规格所起到的作用。
被报告的规格bug
（以下均为三次作业累计数据）
整体规范： 2 （/exist , /all 的书写规范错误·）
Repok： 3 （均为初始Repok不为true）
Requires： 1 （前置条件不齐全）
Modifies： 1 （不齐全）
Effects： 6 （后置使用自然语言，后置条件没有完成覆盖）
被报告的规格bug的反思：
其实规格难写的主要原因还是在于设计类和方法的时候根本没有按照规格耦合的方法去走，当出现了上帝方法的时候，纯布尔表达式的方法是怎么样也没法保证后置条件的覆盖的，而当出现笨蛋方法的时候，一个个鸡肋写起来又尤为的绝望，如果一一复制粘贴又容易出现自己没有注意到的错误。
其实我对课程稍微有一点点疑问，如果一开始就打算进行规格化训练的话，是不是不要以补充的形式完成第一次规格作业比较好？毕竟人的思维明显是有惯性的，再加上先代码后规格的确符合大多数非专业程序员（比如我这种菜狗）的习惯，大多数人写写规格已经只是场面活了。
功能性bug及其反思：
其实这几次作业主要的功能性bug就是沿袭下来的两个：过多指令造成的寻路系统压力崩溃和流量刷新累积误差后不同步。这两个bug多次作业用了各种解决方法，虽然是成功的大幅降低了其出现的概率但一直没有根除，前者和我采用的寻路算法有关，后者真的可能是我整体程序设计太臃肿导致误差时间过大了，
由于两者都是牵一发而动全身的部分，导致在这几次debug中我也是只能不停的饮鸩止渴不敢全盘推翻，根本原因还是在设计的时候没有做出合理的结构规划导致耦合太紧。
心得体会：
课程希望我们先规格后代码，然而一直设计的却是写好代码补充规格的模式，这是不是有一点自相矛盾?而且，相信课程组的各位也是在代码中补充规格写到尽善尽美是一件多么困难的事吧，还是说课程组原本就想的是逼迫想要拿高分的同学完全为了JSF重写自己的出租车作业？
这门课开始变成面向运气的确有很大程度是因为这个JSF，真的是想挂满就挂满，想不挂就不挂，而且这个挂满和不挂和测试者自身的测试能力是一点关系都没有的...我看大多数是有时间撕逼到底的人赢，没有时间撕逼的话就乖乖认命送分呗（比如我），虽然我个人是真的不怎么在乎到底多少分，虽然测会认真的测但在扣分这一件事上也有消极比赛的嫌疑（只要能够体现自己能力，发现问题，不要影响我通过课程一般不较劲），可是对于某些积极对待这门课程的同学而言，这几次作业无疑对他们是一盆冷水泼头。诚然分数很难成为变成能力的直接体现，但当二者几乎一点相关度都快没的时候，是否应该反思一下课程的设计呢？