作業要求：https://edu.cnblogs.com/campus/ustc/InnovatingLeadersClass/homework/2231

源碼地址：https://github.com/YueshangGu/golden-number

黃金點遊戲簡單介紹

假設有M個人參與黃金點遊戲，每輪遊戲每個人提兩個(0, 100)間的有理數，共2M個數，求這2M個數的平均數再將這個平均數乘以0.618得到這一輪的黃金點，提出離黃金點最近的數的人得2M分（同樣近的人一起得分），離黃金點最遠的人扣兩分。

在本次實驗中，我們需要寫一個bot來在每輪遊戲中自動提出兩個數，每次遊戲前，bot能拿到之前所有輪次遊戲的每個人提的兩個數和黃金點，每場遊戲共進行400輪，共有上半場和下半場兩場遊戲，累計得分最高的bot獲勝。

我們的策略介紹

我們放棄了預測每一個對手的輸出和使用強化學習等復雜算法的方案。相反，我們使用簡單的統計策略，利用前n局的黃金點的信息，對當前黃金點進行預測。我們采用一個隊列，對前n局的黃金點信息進行統計，並且根據一定的劃分和更新策略，我們可以得到m(\(m \leq n\))個黃金點，然後我們根據隊列中概率最大的兩個黃金點進行輸出。

PSP表格記錄預估時間

我們的項目開始時，並沒有考慮利用PSP表格預估時間，在後面的實驗中，我們會改善此方面。

接口設計

由於我們的bot僅僅只需要一個前n個黃金點的統計隊列，以及待選黃金點的更新列表，所以我們預打算一個函數實現所有功能，根據當前history信息，返回插入和更新後的待預測黃金點列表和近50輪的統計隊列。主函數根據返回的信息進行輸出。

接口實現

我們的程序功能十分簡單，只有兩個函數，沒有class，所以並不需要流程圖的表示。另外在設計的過程中，我們的算法考慮到了存在少數人搗亂的情況，可以去預測兩個黃金點的極限值。另外對於大家更改策略的行為，我們的隊列也能夠很快的得以適應。

UML圖

僅有2個函數，沒有類，沒有實體，所有並不需要UML圖的表示。

Design by Contract

• DbC的優缺點
  • 優點在於代碼調試很簡單，每一個過程的行為意圖都定義的非常清楚，且不能夠被違反。另外因為關於代碼實現的契約已經文檔化，所有有利於代碼重用。
  • 缺點在於實現代碼之前，會花費很大的時間和精力，去商討代碼契約，規則較強，可能後期根據實際情況也需要修改。
• 我們方法中的體現
  我們在這次編程的任務中，由於任務比較簡單，關於接口的交流較少，所以並沒有采用這種設計方式。

結對共識

我們分工合作，在編程之前就已經互相商量了應該傳入的參數和返回的結果，采用簡單的註釋，我們便達到了共識。在編程中沒有遇到異常。

UI模塊

我們並沒有UI模塊，所以並沒有UI模塊的設計和其他模塊之間的對接部分。

結對過程

我們的結對過程非常的愉快，在合作中我們互相學習，共同的進步。

下面是我們正在討論的過程。。。

結對小夥伴

我們在結對過程中，采取的是駕駛員和領航員靈活的合作方式。通過指導監督和執行的交替合作，我們獲得了更好的合作體驗。

• 結對編程的優缺點
  • 結對編程有助於雙方互相學習對方的優點，為合作提供更好的代碼質量和設計質量。
  • 合作雙方有更大的積極性，能夠參與到合作中。
  • 有的時候，會出現雙方互相甩鍋的情況，會使得合作的效率大大降低。
• 合作夥伴的評價
  • 我的合作夥伴Kai Hu，是一個非常積極聰明的小夥伴。在討論階段，能夠提出非常creative的idea，在代碼實現時，也能夠首先承擔起coding的責任，且能夠在整個過程中不斷的提出非常有意思的改進的意見，所以沒有缺點:)

實際花費時間

這個在我們的實際過程中並沒有記錄，所以無法進行對比。

其他收獲

在這次的比賽中，我們的方法比較簡單，主要是我們擔心復雜的算法會花費我們較大的時間精力，最後結果也不是很好。所以了，一分耕耘一分收獲，沒有付出，就沒有回報。在以後的作業中，我們會認真的對待。

現代軟件工程 第二周博客作業