作業要求: https://edu.cnblogs.com/campus/ustc/InnovatingLeadersClass/homework/2231
專案原始碼: https://github.com/jackroos/golden_number

本次作業我們是設計一個玩黃金點遊戲的Bot，遊戲的要求如下:

專案計劃和實際實現

(我們沒有設計這個PSP表格，但是回想當時的想法我大概估計了一下)

我們開始的想法太美好了，企圖用強化學習一步到位,沒有計劃設計複審，然而訓練出的效果並不好，所以到最後又花了大量時間重新設計和分析我們的bot.....，重新複審設計...

介面設計

演算法的核心：
假設其他玩家提交資料的和上一輪黃金點強相關，統計各個玩家提交資料均值和上一輪黃金點的比例的概率分佈，同時對於估計搗蛋的玩家(比例過大或過小),統計搗蛋值的平均數，通過上面的資訊加權平均來獲取每人下一輪最可能的提交值。

最終提交的版本是bot0.py,程式碼很簡單。主要分為以下幾個函式

三個函式的關係是：
入口是bot函式,bot中傳入歷史資料呼叫get_stat獲取概率分佈,得到的值傳入pred預測他人提交,計算出我們的提交黃金點輸出。

沒有面向物件程式設計，函式邏輯也很簡單，所以UML類圖好像沒有必要...

Design by Contract

契約式設計（英語：Design by Contract，縮寫為 DbC），一種設計計算機軟體的方法。這種方法要求軟體設計者為軟體元件定義正式的，精確的並且可驗證的介面，這樣，為傳統的抽象資料型別又增加了先驗條件、後驗條件和不變式。
By Wiki

優點是：保證了函式各司其職，只處理規定好的滿足前置條件的輸入，保證輸出等滿足後驗條件。同時也可以看成一種程式碼的規範和契約。
我們結對程式設計中，並沒有顯示的使用斷言語句來進行這種契約式設計。只是簡單規定了輸入輸出格式,沒有用assert等檢查，這也是我們之後要注意的點。

規範和異常處理

程式碼規範我們主要預設python的縮排是4個空格,大家都不取沒有意義的名字等，並沒有明確的約定別的規範。設計方面，保證函式各司其職，異常處理方面，主要是程式碼中一些可能除0的地方，我們簡單的加上了0.001防止除0，別的沒有進行什麼異常處理。

介面

描述介面模組的詳細設計過程。你的程式有使用者介面麼？在部落格中詳細介紹你如何設計你的介面模組。
描述介面模組與其他模組的對接。詳細描述UI模組的設計與其他模組的對接，並在部落格中截圖實現的功能。

沒有介面,此條不適用，因為已經給出了模擬覆盤程式的UI，我們的程式也比較簡單...

結對程式設計過程

專案一開始，我們進行了討論，採用強化學習的策略，這時候需要大量的資料，因此我們的方案是寫一些簡單的Bot和一個模擬伺服器的程式，來訓練我們的Bot。但一方面我們自己設計的Bot太簡單了，另一方面可能強化學習的狀態和動作定義的不是很合適，學出來的Bot感覺在過擬合數據....此時時間已經很緊迫了，我們決定採用基於統計的簡單策略Bot，ddl的前一晚完全推翻了之前的方法，兩人重新來過。在專案的一開始，我們急於快點搞出來一個Bot,採用分工的方式，後來發現效果不好後，採用領航員和駕駛員的模式。發現的確有bug的時候對方都能實時指出，而且如果一方思路不明確的時候，另一方能及時提醒和梳理。
(照片忘記照了....gg)

我的優點：

• 比較善於找bug,有bug能及時提醒
• 比較及時的和隊友溝通對專案的想法/策略
• 耐心的測試和複審
  缺點：
  對numpy這些不太熟悉，導致在這些點上有時候被隊友帶著走(隊友非常確定沒有bug,我就選擇相信了他，然後最後測試的時候發現這個拷貝還是出問題了..)

隊友的優點:

• 對numpy之類的非常熟悉
• 能很快的有思路，清整個專案的思路
• 對我不靠譜的想法也樂於傾聽，分析哪裡不對，改進之後採納
  缺點:
  寫程式碼有些粗心

其他收穫

我們的專案在兩輪裡結果差異比較大...還是因此程式沒有根據一些結果的反饋來挑戰自己的策略，前提假設性較強，也不能實時的學習。同時，之後要注意好對時間的規劃。