[BUAA OO]第三次博客做業

OO第三次博客做業

一、 規格化設計的發展

我認爲，規格化設計主要源自於軟件設計的兩次危機。第一次是因爲大量存在的goto語句，讓當時被普遍應用的面向過程式的編程語言臃腫不堪，在邏輯性上與工程規模上魚與熊掌不可兼得。故而，人們提出告終構化程序設計的編程思想，旨在使程序實現結構化設計的思想。這種設計思想旨在控制各個模塊的程序複雜度，從而保證總體工程的正確性。

然而，因爲硬件設備的快速迭代，對於軟件的要求也愈來愈高。工程的日益龐大、面向過程程序的可擴展性差、可維護性有限，使得人們提出了面型對象程序編程的思想。而面向對象程序編程之中，模塊的對接是必不可少的。爲了使本身的程序不至於讓他人沒法閱讀，也不至於讓其自己顯得過於臃腫。一個良好的規格化設計顯然是必須的。

 

二、 JSF不規範寫法

這幾回做業個人運氣能夠說是比較不錯，第九次做業JSF寫的不是很認真，許多不太好描述的後置條件都是用天然語言寫的（當時也不太清楚符合規範的寫法是如何，在後面的上機課上看到老師寫的才明白），可是互測的同窗並無申報。。。第十次做業在這方面有所改進，可是仍是存在着modifies中因爲對傳進來的對象參數自己進行修改，故而我寫的是modifies：該對象參數，被測試者申報書寫不規範。在一番爭論以後，我也明白了這種看似聰明的寫法無疑是偷懶。也就服從了測試者的判斷，根據規範修改了代碼的規範。第十一次做業因爲個人代碼相比第十次的，沒有大量的更改，而老的問題也已經修復，因此也沒有被測試出不規範問題。

 

 

三、 JSF寫法改進

1改進前：

 

1改進後：

 

 

2改進前

 

 

2改進後

 

 

3改進前

 

 

3改進後

 

 

4改進前

 

 

4改進後

 

 

四、 功能BUG與規格BUG的聚焦分析

個人功能bug與規格bug並沒有明顯聯繫，個人規格bug主要是由於我第一次不太會寫，第二次在有些地方寫的不是很清楚致使的。而個人功能bug是因爲我沒有即便看羣聊天和issue致使的（這點真讓人很不開心，指導書裏面對某一個程序功能並無要求，而在微信羣裏面助教解答問題的時候竟然要求了，真是讓人沒法適從），核心功能上三次做業並無出現問題。

 

五、 設計規格和撰寫規格的基本思路和體會

我認爲一個好的規格，首先要求咱們對於這段函數的功能設計上就要清晰。好比對於傳進來參數合理性的判斷，也就是前置條件，咱們是應該統一放在調用函數以前，仍是該函數體以內，這樣細小的設計雖然不會影響咱們程序的執行，可是對於一個良好的程序規範，統一的規格顯然是必須的。其次，咱們的規格要寫的儘可能清晰。就好比我第十次做業被測試者找出的bug就是一個很好的錯誤示範。對於對象參數的修改只寫該對象的名字，並不能讓人很明顯的知道這個函數究竟對什麼進行了修改。而上機課中老師們所寫的規範就很是值得咱們學習，咱們甚至能夠根據老師們所寫的規範，反向寫出、補全甚至修改不正確的代碼，這就體現了規範在程序可維護性上的重要體現。