本周結對編程追加作業：記錄收獲。坦白說，我的收獲多而雜，一時不知從何說起，以下試圖從各方面簡要談談。

一、編程能力收獲

　　從編程能力方面，我收獲的主要是類的設計思路和算法設計。在作業要求blog的指引下，我和同伴一同思考、選用類，最終決定采用我提議的方案，類中的變量名、變量數量都是由我提議和設計完成的，主要基於要求的功能的實現。變量以外，還需要設計類的函數，這就涉及到算法層面。一開始，我對於生成運算式方面非常生疏，翻了半天譚浩強紅皮書，又在團隊作業的小組中討論了一陣，終於決定采用樹的形式生成，輔以棧形式實現。相關函數及代碼可以參考我的作業報告博客，都附有一定的註釋。

　　除了主幹程序外，還有單元測試的設計。由於運用VS單元測試框架時還比較生疏，我和同伴一起找了一些文檔查閱，實現了比較基礎的單元測試，但覆蓋率沒達到百分百。這主要是因為一些涉及全局變量、類變量的函數的單元測試函數編寫方法我們沒能掌握，只能使用斷點debug方式代替單元測試，某種意義上做到了全覆蓋。只能說單元測試之路任重而道遠，在將來的團隊項目中一定要好好落實真正的單元測試。

　　這次編程暴露出我數據結構方面的薄弱，選用完數據結構後，相關算法的編寫也花了很多功夫，和同伴一起找了許多網站和資料作為參考，磕磕碰碰才最終完成，這使我對樹結構、棧結構的操作和使用更加熟悉，也鍛煉了我對於編程細節、邏輯嚴密性的把控，全方位提升了我的編程能力，但願我能牢記這些相關知識，靈活運用在以後的學習工作中。

附圖：類設計與類函數的部分截圖

二、接口相關收獲

　　之前從未將一個程序發布成dll，因而這第一次寶貴的經歷自然伴隨著各種困難。其一，按照網上的教程，我只能從零編寫出非常基礎的dll，卻無法將已經編寫好的cpp文件轉換成dll。最終，在團隊組的同學們的建議下，我和同伴終於找到了方便可行的轉化方法。其實說來也簡單，只要在頭文件頂部添加預編譯，在需要輸出的函數前加上編譯頭即可，完全沒必要像網上教程一般新建一個dll工程、預編譯頭等等繁雜操作。

　　以上就是關於接口的全部收獲？當然不可能。這僅僅是開始。我們還沒來得及沈浸於dll導出成功的喜悅，就被對接的UI組問翻了：為什麽給的頭文件裏這麽多內容？函數接口能不能多支持一些格式？

　　我們下載了群裏其他組的配套頭文件，發現其中僅僅含有需要輸出的函數，而我們的頭文件可謂無所不包：類定義，類中函數的定義，五臟俱全。於是我們恍然大悟，又設計了一個func.h文件，將需要導出的函數封裝在其中，其他的信息則無需提供給UI。同時，我們改善了接口種類，原先UI需要先生成一個questionCore 類的變量，再調用變量.setting函數進行設置，再調用變量.getfile函數獲得結果，非常復雜，且每個參數都需要設置；改善後，我們只提供三類setting函數，分別支持string輸入、bool輸入、文件輸入，且自帶輸出，UI組只需選用其中的一個setting函數，就能直接得到結果，且對於不想設置的選項，可以輸入-1、“”來取用默認值，非常方便。

　　這次接口的設計波折給了我很大啟發：接口的設計要盡量簡單化、多元化、智能化，編寫的dll要力求實現“完美黑盒”，給用戶提供最便捷、最舒適的體驗。

附圖：原先設計的接口，只提供一種類型的設置函數，且需要繁復的調用手續。

附圖：改進後的設計接口，只提供三種setting方案，方便快捷，支持使用默認設置。

三、交流相關收獲

　　結對作業的一大命題便是交流。我和隊友的交流還算融洽。雖然他沒有上過數據結構課，對樹、棧等數據結構不太理解，但經過簡單講解以後他能很快follow上，並且提出了許多好的意見，比如篩選不合法式子的判斷準則、括號添加和刪除的功能等。在與隊友的交流合作中，我學到了如何將自己的設計思路傳達給同伴，學到了通過畫圖方式展示函數的架構（在隊友的強烈建議下），也學到了意見出現分歧時應該如何協商解決。

　　除此之外，還有不同組間的交流。由於每組都要相互對接，我們與不同的UI組間基本都要打交道。第一次面對面對接時，由於我們沒有說清楚功能，UI組調用方式出錯導致遲遲不出結果，經過我們共同調試、發現問題，最終得以順利對接。後來對接時，我們積極吸取了各UI組的建議，並結合群內做得比較好的UI組的接口設計作為參照，不斷更新我們的對接功能，讓我們的程序變得更易於使用。這些交流合作中，我學到了如何給自己的產品打廣告，如何從他人的建議、示範中提升自我，如何給他人提建議，幫助他人完善功能。

附圖：在與UI11組的對接中，我們發現界面的分辨率存在問題，導致顯示不全，於是及時向他們反饋、建議，得到解決。

　　總而言之，本次結對編程給了我諸多益處，接下來的團隊項目中，我一定要好好總結、做得更好。

結對編程收獲-Core10組-PB16110698