OO第三次總結

（一）總結介紹規格化設計的大體發展歷史和爲何獲得了人們的重視

　　早期程序的代碼量不是很大因此人們沒有意識到規格化設計的重要性，但隨着人們需求的增長以及程序功能性的加強，程序代碼量愈來愈大，一我的沒法完成龐大程序的編寫和維護的工做量，但編寫代碼的人不必定會是維護程序的人，在閱讀代碼進行維護時給維護人員帶來巨大的阻礙。因此代碼規格應運而生，經過代碼規格能夠更快的瞭解相應代碼的功能而不須要去閱讀源碼。大大便捷了程序團隊編寫和程序的維護。所以規格化設計愈來愈獲得人們的重視，併成爲業內的共識。

（二）規格bug分析

3次互測中都沒有被找到規格bug，但本身的規格撰寫仍是有待提高的。

（三）規格很差寫法的改進

 

REQUIRES	原寫法	改進寫法
sortPath	src != null; dst != null;	0<=src.x<80 &&0<=src.y<80 &&0<=dst.x<80 &&0<=dst.y<80
initmatrix	None	map!=null
OpenPath	p1!=null&&p2!=null	p1!=null&&p2!=null &&graph!=null &&road!=null &&map!=null
Req	time!=null &&src!=null &&dst!=null;	time!=null &&0<=src.x<80 &&0<=src.y<80 &&0<=dst.x<80 &&0<=dst.y<80
gettime	None	this!=null

EFFECTS	原寫法	改進寫法
offer	\!IfIn ==> Grabque.offer(taxi); taxi.creditUp();	(old)Grabque.contains(taxi) == false ==> Grabque.contains(taxi) == true &&Grabque.size() = (old)Grabque.size() + 1
poll	\result == reqs.poll();	(old)reqs.isEmpty == false ==> \result == (old)reqs.poll() &&\(old)reqs.contain(\result) == false &&reqs.size == (old)reqs.size - 1
INFO_all	(\all int i; i<num.TAXINUM ==> System.out.println(taxis[i].comString());	(\all int i; 0<=i<num.TAXINUM ==> System.out.println(taxis[i].comString());
PointManager	\this.n == 0; * \this.points == 出租車在從搶單位置到服務完 該次請求所通過的全部的Point序列;	\this.n == 0 &&(\all int i; 0<=i<record.pickpath.size ==>\this.points.contian(record.pickpath.get(i)) == true &&\this.points.size = (old)\this.points.size + 1;

 

(四）bug與規格分析

	bug
第九次做業	未被測試
第十次做業	邊界上紅綠燈沒法變換
	沒法打開關閉的道路
第十一次做業	未按照最小流量跑

感受功能bug和規格bug目前看來還沒什麼明顯的關係。由於目前爲止都仍是先寫的代碼再寫規格。

（五）心得體會

這三次做業的代碼量相較前一輪明顯少了很多，主要是爲了培養咱們代碼規格的撰寫規範。但不是每一個人的水平都達到了那種境界——就是先寫規格再寫內容，大部分同窗應該還都是先寫的內容並debug後再進行規格的撰寫，但兩次上機實驗課讓我明顯體會到了規格撰寫的重要性，有了一個描述無缺的規格再對內容進行編寫是很容易的一件事。因此規格撰寫水平的提高對程序員來講很是重要，本身也須要多花點心思在這方面上。