哈哈哈哈哈哈哈哈哈终于又到博客周了！
程序设计规格化
程序开发过程涉及到多种程序员的工作，一个模块可能会被多个使用者用到，所以这就带来了程序使用方式不统一的问题。为了解决这一问题，避免程序使用者的逻辑与程序设计者的初衷相违背，促进整合这些不统一的标签与框架，从程序设计的角度出发，就产生了规格化的程序设计。
程序设计语言的三次分离使软件技术产生飞跃 1950年代，第一次分离，主程序和子程序的分离 程序结构模型是树状模型，子程序可先于主程序编写。 通过使用库函数来简化编程，实现最初的代码重用。 产生基本的软件开发过程：分析—设计—编码—测试，使大型软件系统的开发成为可能 1975—1980年代，第二次分离，规格说明（Spec）和体（body）的分离 说明是类型定义和操作描述，体是操作的具体实现。 （具体的例子就是C++,Java等面向对象语言的类说明与类实现的分离。） 解决方案设计只关注说明，实现时引用或者设计体。 体的更改、置换不影响规格说明，保证了可移植性。 支持多机系统，但要同样环境。 此时产生了划时代的面向对象技术。 1995—2000年代，第三次分离，对象使用和对象实现的分离 基于构件开发： 标准化的软件构件如同硬件IC，可插拔，使用者只用外特性，不计内部实现。 Web Services： 软件就是服务。分布式，跨平台，松耦合。
第九次作业：
新添了开关道路的功能，以及用load文件初始化的功能，我的bug是：
1、处于等待状态随机走动的出租车无法检测到道路开闭变化；
2、load一个不存在的文件程序crash；
3、effects不完整。
首先第一个bug是因为道路开闭的处理我只更新了邻接矩阵而没有更新地图数组，而出租车随机走动是基于地图数组的，这一点疏忽了，我以为自己很了解我的程序，但其实...emmm以后不能太草率。
第二个bug真的好亏啊，我以为只要在main函数写try-catch就能抓住所有异常，却忽视了这次写的是多线程作业，Oh这不是我写出来的程序= =
第三个忘记给某个方法的effects写返回值了，这里墙裂提醒大家改函数的时候千万别忘记改规格！！！
第十次作业：
新添了交叉路口的红绿灯，说实话GUI的红绿灯真是...优雅 简陋 呢
不过这不是重点，还是说说我的问题扒。
1、我觉得这是最严重的问题并且可能会伴随整个出租车系列作业的问题，就是红绿灯路口闪现问题，据观察，出租车经过红绿灯路口时偶尔会跳过某个点往对角线方向移动。emmm因为这个问题我被挂了三个点，有点亏，但是错了就是错了，没什么好讲的。
我认为是更新时间的问题，于是我修改了代码，但也仅仅是降低了这种情况的发生概率，由此看来选用一个好的架构真心很重要，目前正在想办法解决╰（‵□′）╯
2、这是个很搞笑的问题，不可以打开关闭的道路，我的理解是如果输入打开道路的指令，程序必须得打开，所以就后知后觉了...这波很亏
3、规格问题。主要是requires不完整，比如传入参数为对象时没有判断她是否为null。
另外，这次作业被测试者改红绿灯间隔时间为5s，出现了出租车满天飞的鬼畜现象，不幸成为了吐槽版的笑柄，看完我都笑了呵呵哈哈哈hhhhh
第十一次作业：
新增加了炒鸡出租车乘客服务历史的双向迭代器查询方式，但是这个功能似乎没有体现在bug树上。
尽管经历了这么多次出租车作业，规格的bug永远存在的，找不完的。
那我还是先说功能bug扒。
1、不可以打开关闭的道路。没错又是这个讨厌的bug，为什么没有de掉，不是我没有改，只是不小心把MAXSIZE写成了0，然后就跟没改一样。
2、没有按最短路径走。这只能是spfa写错了，或者是线程切换导致的路经计算问题。我想先排除spfa的问题，确认过眼神，代码与百度的伪码一致。那么就是线程切换的问题了，路经计算方法是在地图类中的，而地图类是所有线程共享的，可能争夺地图类资源的线程有出租车管理类和调度器类，出租车管理类需要计算最短路径，而调度器类需要计算抢单的出租车中距离乘客最近的车，但他们共享同一个地图对象，因此我认为在调用路径计算方法的时候给地图类加锁应该就没问题了。
3、还是红绿灯路口闪现的问题，尽管降低了发生的概率，还是无法完全避免，还是得再优化一下。
4、规格类bug：没有按照jsf规格写，确实这个前置条件很难描述，但已经不是第一次被扣自然语言了，那对于这种难以用逻辑语言描述的前置怎么处理呢，我认为可以稍微放宽限制，比如以下这个例子的前置可以改成“st!=null”
private void ordercase(String st) {
/**
* @REQUIRES:st is a valid order;
* @MODIFIES:oh.orders;
* @EFFECTS:oh.orders.contains((Passenger)st);
*/
还有这个错误例子：（effects用了自然语言，可是该怎么描述地图更新呢？目前我能想到的办法就是把更新过程用逻辑语言描述了。）
private void lightcase(String st) {
/**
* @REQUIRES:st is a valid order;
* @MODIFIES:light;
* @EFFECTS:update light map;
*/
心得体会：
已经是经历过六次OO互测的人了，遇到过好人，也遇到过坏人，也不能这么说，只要程序还有bug，错了就是错了，没必要为一个小小的问题和同学争执，如果连这点事情都处理不好，以后还怎么当一个合格的程序员呢。
多线程也写过六次了，遇到了不少多线程引起的问题，尤其是加锁的问题。这里我得吐槽一下新添红绿灯的作业了，由于我的程序一直是由一个类管理100辆车，所以更新时间统一是500ms，但是加了红绿灯，每个车的更新周期会有所不同，考虑过改成100个线程，或许是因为之前太少线程了，有些代码段没有加好锁，突然新增100个线程，甚至GUI都不会动了呢，硬是折腾了一下午，减少了这种情况的发生，但还是无法避免这个问题。所以后来我又改成了1个线程管理100个车，只不过对每辆车的更新周期都不同，这样能避免不少多线程引发的死锁问题，GUI也顺畅很多。
OO快结束了，大家都要加油鸭！