第三次博客做業JSF

JSF規格化設計發展史以及爲何獲得人們重視

查閱了n多資料可是仍然沒找到。

就說一些jsf的優點吧。

優點：    （1）UI組件

　　　　（2）事件驅動模式

　　　　（3）用戶界面到業務邏輯的直接映射

　　　　（4）程序員和網頁設計的人員分工

　　　　（5）請求處理生命週期的多階段劃分

　　　　（6）伴隨工具而生存

　　　　（7）全面的用戶自定義支持

　　　　（8）Web開發的官方標準之一

參考連接：JSF的優點及將來發展趨勢

 

被報告的規格bug

JSF bug	緣由
REQUIRES：1	沒有判斷參數條件
MODIFIES：0	無
EFFECTS：3	沒有使用布爾表達式 不完整 判斷「==」寫成「=」

 

 

 

 

 

 

 

 

第十次做業中不管方法代碼長短（即代碼行數無參考價值），都出現了這些bug,長代碼仍然難以改正

第十一次做業修正了除了run方法之外的其他短方法，可是任然漏了==號

 

規格bug產生緣由

短方法開始並無重視，長方法因爲代碼上百行（例如整個taxi的狀態轉移算法都實如今了run裏面），jsf無從下手，只好寫個描述了出租車運行狀態轉移變化。

jsf參考文檔並未理解精髓，總想着使用天然語言水過去，可是測試者不放過。

 

列舉前置後置條件很差的寫法

（1）天然語言，雖然開始算對可是用天然語言確實不太好（可是分高啊）

（2）對於多種能夠合併的判斷條件沒有合併，條件過長

（3）表示模糊，泛泛帶過

（4）格式不一致

（5）對於帶鎖多線程額外規格未處理

修改方案：必定要使用布爾表達式，不要再籠統蓋過，方法寫短，判斷條件可合併簡化則簡化。清楚本身實現的究竟是什麼功能，仔細寫規格。對於帶鎖多線程加上新規格。

 

分析

方法	功能bug	規格bug
main	3	1
scanftxt	4	1
一些短方法	0	2

 

 

 

 

我的認爲規格bug和功能bug並無直接的聯繫，長方法實現功能多，規格就一個，短方法每每功能不出錯反而被扣規格。

 

體會

能認真改的地方就改一改，雖然改了也可能會被扣，但不改更可能。

屢次繼承的做業必定要仔細修訂先前錯誤，不然越後期越難改。

但願能把代碼寫的愈來愈優秀，不被測試者噴格式垃圾（又沒辦法反駁畢竟他說的沒啥不對）。