基於度量分析程序結構

第五次作業

第六次作業

第七次作業

分析自己程序的 Bug

經過了前三次作業的“教訓”，我嘗試不看任何的 issue 和微信群答疑，只看指導書來完成本次作業。

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

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

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

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

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

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

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

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

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

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

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

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

與之相反，“摸魚”指的是我們把拿到的測試代碼，放在那裏，不管它，就好像雖然我們的目標是去捉魚，但是我們只把手伸進水裏，摸一摸就行了。

心得體會

從線程安全和設計原則兩個方面，我得到的體會是：這三次作業我仍然是在周三的淩晨寫完的，我覺得這樣對我的身體不是太好，以後還是周二寫完吧。

2018春 OO第二階段總結