OO第三次博客

 

3

//

//

首先，在開始寫這篇博客以前，我忽然想不起來此次做業是要回憶第幾回做業了，這幾周我對OO的熱情已經歸於0點，還有點負溫了，自嘲一下，當初電梯的時候我仍是第一個發issue的人（笑）。

規格化發展史

20世紀60年代，軟件出現嚴重危機，Dijkstra提出了goto語句的危害，由此引起了軟件界長達數年的論戰，併產生告終構化程序設計方法。Pascal語言在20世紀70年代佔有統治地位。

隨着計算機技術的發展，結構化設計語言和結構化分析沒法知足用戶的需求，OOP由此應運而生，即面向對象的程序設計。OOP的誕生是程序設計方法學的一場革命，大大提升了開發效率，減小了軟件開發的複雜性，提升了軟件的可維護性，可拓展性。1990年以來，面向對象分析、測試、度量和管理研究都獲得長足發展。

規格化設計伴隨OOP而生，爲了提升程序的規範性，對類、方法等進行規範化設計，有利於程序的模塊化劃分。這樣設計程序的數據更加安全可控，測試也變得容易，軟件的維護性獲得提升，於是受到程序設計人員的重視。

bug列表

bug類別	bug內容	出現位置
搶單服務->無車響應不告知乘客	未在readme中說明如何使用修改邊連通與否的指令	readme
搶單服務->搶單窗口大小不正確	同窗你是沒看答疑區吧，助教說了不能禁止指定出租車狀態爲服務或接單狀態	issue
出租車運行一個時間不對	時間有誤	Timepasser.timepass
Effeccts邏輯錯誤	只寫了充分條件，沒寫成充要條件	TwoSideMessage.TwoSideMessage
JSF不符合規範	方法的jsf寫在方法前面	心中
非法輸入->無換行	沒考慮到測試者違反指導書要求，不保證loadfile文件正確性時的狀況	LoadProcessor.startLoad

bug產生緣由

• 你們都比較想要分數。
• Timepasser循環時的時間粒度太大了。
• 交錯readme了。

jsf很差的寫法

前置條件

None

個人絕大多數函數的前置條件都是None，由於是private的，或者自己就是包內自用的，不過室友所以被報過incomplete，說太簡短了，並且如今也還在仲裁ing，因此應該是很差的寫法。

中文

猶豫了一下，由於我接手的全部測試代碼，要麼是None寫法，要麼是中文寫法，因此既然None寫法很差，中文寫法應該是好的？可是中文不是JSF吧。

後置條件

把最終結果的=換成==，再利用替換移除中間變量

這是我寫後置條件的方法，由於絕大多數函數均可以這麼寫，畢竟絕大多數函數的邏輯都很簡單，只是很簡單的狀態訪問罷了。不過由於容易忘記把=換成==，會被報bug，因此是很差的寫法。

中文

中文不是JSF。

彙集關係

方法名	功能bug數	規格bug數
readme	1	0
issue	1	0
Timepasser.timepass	1	0
TwoSideMessage.TwoSideMessage	0	1
心中	0	1
LoadProcessor.startLoad	1	0

由表格中能夠看出，功能bug和規格bug沒有任何相關性。

基本思路和體會

規格是一種容易出錯的東西，由於沒有編譯器會提示語法錯誤，也沒法進行測試來檢查正確性，因此在實際的工程實踐中應該儘可能避免使用規格。

給課程的話

這門課已經走歪了，我這樣一個已經喪失熱情的人的博客就不用看了，請老師看看那些認真對待這門課程的人此次寫的博客，好好看看他們的bug到底都是怎樣的bug——咱們是學生，分數永遠是第一驅動力，任何爲了分數而努力的行爲都是能夠被稱之爲「學習」的行爲。若是OO這門課並非爲分而學的話，那爲什麼要引入排位制度？咱們已經不是會爲了虛榮、理想而奮鬥的年紀了，都是實實在在、腳踏實地地一點一點地去扣的。