2018春 OO第二階段總結

基於度量分析程序結構

第五次做業

第六次做業

第七次做業

分析本身程序的 Bug

通過了前三次做業的「教訓」，我嘗試不看任何的 issue 和微信羣答疑，只看指導書來完成本次做業。

第五次做業失誤了，沒有正確處理括號的輸入，錯了兩個公測點。

第六次做業 IFTTT 對於文件夾的監控理解不夠到位。

第七次做業作得比較完美。報告書也寫得很漂亮。

分析未經過的公測用例和被互測發現的bug：特徵、問題所在的類和方法
    特別注意分析哪些問題與線程安全相關
    關聯分析bug位置與設計結構之間的相關性
    從分類樹角度分析程序在設計上的問題

分析未經過的公測用例和被互測發現的bug：特徵都是指導書沒說的。

與線程安全相關的問題我是沒有的。

bug位置與設計結構沒有什麼太大的相關性，就是指導書可能沒說。

程序在設計上沒有充分考慮指導書意外的問題。

分析發現別人 Bug 所採用的策略

code-review 或者說測試的代價是很高的，在大公司中一般他們都由技術比較好的人來完成，而且薪酬很高。我由於時間比較少，就（根本）沒有作測試。

列出本身所採起的測試策略及有效性，並特別指出是否結合被測程序的代碼設計結構來設計測試用例
    分析本身採用了什麼策略來發現線程安全相關的問題

我採起的測試策略叫作摸魚，這是個比喻，區別於釣魚。在知名網站編程 codeforces 上，若是你 hack 別人的代碼失敗，那麼你會被扣分，因而有許多人採用了「釣魚」的方法，例如， #define int long long，而後在程序中使用 int。若是你沒有發現這個宏定義，而冒然地認爲它沒有使用 long long，那你就被釣魚了。

與之相反，「摸魚」指的是咱們把拿到的測試代碼，放在那裏，無論它，就好像雖然咱們的目標是去捉魚，可是咱們只把手伸進水裏，摸一摸就好了。

心得體會

從線程安全和設計原則兩個方面，我獲得的體會是：這三次做業我仍然是在週三的凌晨寫完的，我以爲這樣對個人身體不是太好，之後仍是週二寫完吧。