第二次結對編程做業
一、相關連接
031702342黃智鋒
博客連接：http://www.javashuo.com/article/p-kvhkwsdm-gq.html
Github連接：https://github.com/hzf-hhh/fujian13html
031702342黃彬煌
博客連接：http://www.javashuo.com/article/p-ziiluqez-hq.html
Github連接：https://github.com/yaoxuan2018/shisanshui前端
二、具體分工
黃智鋒：負責UI前端和網絡接口的設計，部分博客的撰寫；
黃彬煌：負責出牌算法的設計，部分博客的撰寫。python
三、給出PSP表格（2分）
| PSP2.1 | Personal Software Process Stages | 預估耗時（分鐘） | 實際耗時（分鐘） |
| Planning | 計劃 | 300 | 300 |
| · Estimate | · 估計這個任務須要多少時間 | 52 | 60 |
| Development | 開發 | 5100 | 6800 |
| · Analysis | · 需求分析 (包括學習新技術) | 230 | 350 |
| · Design Spec | · 生成設計文檔 | 140 | 160 |
| · Design Review | · 設計複審 | 30 | 50 |
| · Coding Standard | · 代碼規範 (爲目前的開發制定合適的規範) | 200 | 400 |
| · Design | · 具體設計 | 400 | 600 |
| · Coding | · 具體編碼 | 2000 | 3000 |
| · Code Review | · 代碼複審 | 200 | 300 |
| · Test | · 測試（自我測試，修改代碼，提交修改） | 600 | 720 |
| Reporting | 報告 | 30 | 50 |
| · Test Repor | · 測試報告 | 30 | 40 |
| · Size Measurement | · 計算工做量 | 20 | 30 |
| · Postmortem & Process Improvement Plan | · 過後總結, 並提出過程改進計劃 | 130 | 230 |
| · 合計 | 9462 | 13090 |
四、解題思路描述與設計實現說明
（1）網絡接口的使用
登錄接口
排行榜接口(歷史戰局\詳情用一樣的作法提取出所需)
發牌接口：
出牌接口：
歷史戰局接口（treeview組件插入）
歷史戰局詳情（treeview組件插入）
（2）代碼組織與內部實現設計（類圖）
（3）說明算法的關鍵與關鍵實現部分流程圖
該算法首先是對輸入獲得的字符串進行分割，而後存入列表中。再用到itertools模塊裏面的combinations組合函數從列表中的13個元素任取五個，而後再從剩下的八個中再取5個。最終分紅三份。再對這三份進行牌的類型分析，獲得相應的勝率點，中間再對三墩進行分析，是否符合底墩大於中墩大於頭墩的原則。最後比較勝率點，將勝率點總和高的三墩牌型保存下來。最後輸出。整個算法來看的話，關鍵點，就是勝率點的編寫了，確保相對準確。git
流程圖：
五、關鍵代碼解釋
第一張圖是將13張牌組合成數量爲5 5 3類型的牌堆，爲何說它重要呢？是由於我本身原本的算法是從底墩向上一層一層判牌型，再結合估計可以贏取更多水的機率，最終肯定所要輸出的牌型。可是在判牌型這一關本身所寫的代碼量巨大，而且不保證不會出現問題。最後索性暴力分配再去作判斷，缺少一些藝術技巧吧。可是，真的在用十幾行代碼作完上千行代碼須要作的過後，是真的會感動到聲淚俱下，真救命。
第二張圖是後面作完算法，在和別人比拼運氣算法時出現的問題，常常超時。就好像四劍客PK，其餘三人已經收刀了，另外一個還沒把刀拔出來，已經不是多尬的問題了，已經上升成送了。。後來，排除一堆問題後，只剩下算法了。可是算法又挑不出刺來了，我甚至還對一些狀況進行一個if的特判運行，而後continue掉，但實在想不明白爲啥仍是運行了那麼久的時間。最後是靈光一閃，改掉numpy模塊的zeros函數，一運行，瞬間少了一半的出牌時間。那一瞬間，真的是。。（原諒個人詞語匱乏，過久沒課外閱讀和作語文卷子了~）
github
六、展現性能分析圖和程序中消耗最大的函數（1分）
性能分析圖:
消耗最大的函數:
七、單元測試（5分）
部分代碼（主要是比較和輸出）：
測試函數：
https://github.com/yaoxuan2018/shisanshui/blob/master/%E7%AE%97%E6%B3%95算法
構造函數理由
其實是測了好幾組，但在這裏就展現出上面的兩個比較有表明性的數據。一種是隨機的，另外一種是特殊牌型。之因此用到特殊牌型是由於實際上在寫AI算法時沒有分類，可是特殊牌型又比通常牌型來的大，若是可以按最優的來出，那其他也差很少了。隨機的話，你們應該都懂。就看他出牌合不合理，會不會出現相似把炸彈拆了作對子一團糟的牌。網絡
八、貼出Github的代碼簽入記錄（1分）
九、遇到的代碼模塊異常或結對困難及解決方法（8分）
編寫前端，接口遇到的困難，嘗試：
編寫前端是選擇裏面的圖形化界面tkiner庫，因爲剛開始對這個庫不熟悉，還一度想轉戰pyqt，瞭解一下打擾了，更難，最後仍是繼續研究tkiner,甚至花了很久去設計佈局(起初不知道有place函數，網上的狗屎教程)，最後還利用了墨刀來設計界面（有帶座標，超級方便），佈局以後就是設計界面之間的交互，經過按鈕來實現，花了好久時間搞清楚按鈕函數裏的參數（蛇皮self參數）。
問題是否解決：
問題最後均解決
有何收穫：
掌握了一些編寫前端的小技巧，其實前端跟原型設計相同，只是按鈕功能須要本身設計，我的仍是很喜歡前端這一方面，看到好看的界面交互，內心的成就感仍是蠻大的。
算法困難：
一開始沒認真閱讀所要寫的具體算法，想固然的認爲是寫判牌算法（難道不是要寫一個小軟件你們一塊兒玩？？怎麼就變成寫個小出牌機了。。）致使白寫了幾百行代碼以及浪費了一些時間還有心態又崩了，自做孽，也是沒辦法。後來，欣喜的發現後，繼續了苦逼的打碼過程。期間，聽取了前輩的建議，從底墩向上一層一層判牌型，而且估計獲勝的機率，以此做爲惟一標準。可是在實現的時候，因爲是相似於深度優先搜索算法同樣須要保存現場，以便後續的搜索，致使變量設置有些多，加上須要考慮的狀況比較多（單就底墩若是能是同花順的，中墩頭墩結合起來就有36種）時間又比較緊迫，最重要的菜是原罪，實在是太難了。後來解決後，又遇到代碼超時的狀況。numpy的內置函數還真是偷時間啊。。
問題是否解決：
可以安詳的寫着這些蛇皮話，這麼聰明的讀者必定懂吧，嘿嘿（是的，解決了。請原諒個人冒犯~~）
有何收穫：
首先是當分類狀況超出本身的能力的時候，能夠嘗試暴力解決。許多時候，暴力能省去許多煩惱。其次是，對於想固然這個缺點，實在是須要一直去注意的，可是又不懂得怎麼去解決，有點麻煩。最後是，不要一直圖取便利。有時候，別人寫的內置函數模板，可能包含了許多本身不知道細節，而這些細節對於本身的需求並沒有關緊要？這樣想，那就不對嘞。他還會佔用你的時間空間，讓你快樂的送分。無用功，有時候仍是很麻煩的。
十、評價你的隊友
致大鋒哥：
值得學習的地方
那個UI界面是真的不錯，我鋒哥的審美找圖作前端仍是值得舔一舔的。而後雖然平時嘴邊一直抱怨着，可是仍是很積極的去完成本身的任務。而且是不帶拖沓，行動能力賊高。自我感受本身就比較隨性，可能會比較拖函數
須要改進的地方
暫時沒有（自私一些說的話，對同伴多一些耐心嘻嘻嘻）佈局
十一、學習進度條
| 第N周 | 新增代碼（行） | 累計代碼（行） | 本週學習耗時(小時) | 累計學習耗時（小時） | 重要成長 |
| 1 | 0 | 0 | 15 | 15 | 學習墨刀的使用和福建十三水的具體規則 |
| 2 | 1292 | 1292 | 50 | 50 | 學習python庫tkiner的使用； |
-
每一个你不满意的现在，都有一个你没有努力的曾经。