結對做業收穫_core組

收穫：編碼以前必須的思考是逃不掉的，並且這一步是磨刀不誤砍柴工，並且會加速之後的步驟

分析：

　　首要重要的事情是：須要完成的功能，理清邏輯關係。咱們要隨機產生必定要求的算式，而且計算出算式的值。

　　其次的事就是那個差點沒讀懂題的要求：重複題目的判斷，爲了實現檢驗重複，最讓我心煩的就是那個奇奇怪怪的斷定條件，並且還有括號的參與，一開始頭腦是徹底暈的。而後纔在同窗的提醒下想到了之前學過如何用二叉樹來表示一棵樹，這個方法最好的地方就是去掉了以前困擾我很煩的括號，因此同窗（外援的重要型就凸顯出來了）

　　最後就是心中就要開始有一顆大樹，心中就要開始編寫代碼，開始規劃整個的佈局了。看了搭檔的代碼才反應過來的操做數的結點和操做符的結點是同一種類，畢竟是同一棵樹的葫蘆娃都應該整整齊齊

編代碼：

　　說實在的，雖然說在假期自學了點c++的基礎知識，並且本身動手寫了...寫了20-行的代碼試了試本身學沒有學懂，可是對於這種較大的工程，較認真的做業這仍是第一次。和隊友在一塊兒編代碼的過程當中，一次一次地被隊友嫌棄本身寫的代碼太麻煩，封裝很很差，調用地很不爽。固然我是一個懶人，寫完了不想再動它，可是仍是得有理有據的拒絕隊友，故意的問了問憑什麼要封裝起來？這樣子不也行嗎？而後每每也就一句話：這樣子封裝好了調用者纔不用關心函數具體是怎麼實現的，若是屢次被調用在修改的時候是無敵的方便主要還不會錯。對，隊友說了這樣的話很多於七、8次了，每次都仍是以爲封裝起來纔對，想象一下想要修改一點點內容結果全工程處處找就以爲可怕。因此，慢慢的知道了，封裝就是爲了集成，就是讓使用者放心，無論咱們怎麼作的只管用就好。腦子裏忽然就換位思考了，就像最基礎的函數調用者，也就是咱們，在使用別人家的函數工具時纔不會去關心是怎麼寫，只管拿來用就好；那麼要讓顧客如此的放心，就該寫好每個封裝。

　　類的成員變量通常不會很開放的公佈示人，因此大都是經過調用函數來實現的，這一點雖然有些煩，一個個兩三行的超短小函數總以爲不爽，可是想一想這樣也就將本身的變量隱藏起來，稍想改動一下也很容易，關鍵是別人就不知道里面是怎麼回事，感受這種神祕感很刺激。整塊代碼全是用調用各類函數實現的。

　　不論是整個工程仍是一個功能較爲複雜的函數都是迭代式、增量式地發展的。爲了寫好我負責的那個後序遍歷二叉樹的過程當中生成表達式而且計算出表達式的值，外帶若是生成的二叉樹非法就還要稍稍修改此樹的部分節點，或者標記其爲一棵廢樹。

　　最開始先是計算表達式的值，由於沒來括號，二叉樹的遍歷過程正好就是計算過程（簡直就是lucky），主要是那時候隨機產生結點的函數尚未寫好，因此就先將求表達式放在哪兒（這一步涉及修改樹->產生結點）。固然就想着正常的套路利用返回值來輕鬆方便的遞歸求值。寫完了求值，而後開寫求表達式，而後就尬住了，由於，求這兩個東西都要用函數返回值才方便，因而乎撞車了，那麼爲了兩者兼容還好以前即商量好了將最終的結果用一個結構體裝表達式和結果，因此就用它了。由於修改函數返回值要改的地方太多了，因而想偷懶直接在參數表上面動手腳，然而效果很很差，更加的麻煩，來來回回修改了四、5次函數的參數表和返回值類型，那天晚上可謂是心累呀，主要是這個函數實現的功能確實有點太多了，是工程中核心函數之一，因此複雜些仍是很正常的。感受整個過程很曲折，若是下次有打好腹稿，心中有樹，有一個較爲明確的思路，就不會在這上面糾結了。

　　每次給函數增長功能的時候，記住！記住！記住！要反覆檢查一下功能之間的銜接，是否衝突！否則bug玩死你！

　　入口檢驗很重要，講道理每個函數都應該有一個入口檢驗，即便是一個確切永遠不會發生的錯誤也得有入口檢驗！內部函數要加入口檢驗，提供給外部的函數更加要加入口檢驗！

測試檢查：

　　爲了在本身測試中徹底找到bug，咱們都無論使用者是否是小學生，真當一羣猴子在閉着眼睛敲函數。將全部的參數狀況所有測試了一遍，幾百種狀況挨個挨個來，最後好事發現了一個很關鍵又不是很重要的bug，由於使用者是小學生因此應該不會讓參數太大，以致於計算過程當中的數值超過了一個long long 能夠承受的範圍，起初還想着不用管，可是誰知道對面的使用是什麼物種，仍是將這個bug很重視的用異常處理解決了一下下（頭一回用異常處理，好緊張的，雖然幾乎不會觸發這個異常）。

對接：

　　UI組和咱們core組的關係就像是，程序員和顧客的關係，咱們在決定接口的時候就在想，應該怎麼辦才能讓咱們的用戶（UI組）用得方便，開心，仔細琢磨了一陣對比了二、3個想法仍是提供一個惟一的接口函數是最簡潔方便的了。只要咱們的內部處理好了，寫好API文檔應該不會有大問題，提供函數的好處就是，封裝了設置參數的過程，一樣是讓UI組遠離核心細節，看不見內部的實施過程，就像開開心心地調用系統函數同樣快樂！

最後：

有一組不一樣於其餘組用的文件的形式，而是用讀取內存的形式，還好因爲以前對於對接時不清楚UI組的接受方式，因此作好了兩手準備，原型就是讀取內存的內核，外包裝是本身輸出文件二者一前一後徹底不衝突，這讓咱們對接時很方便的修改爲了文件、內存兩者兼容的模式。這讓我知道了，即便不清楚目標的方向，那麼就要把全部可能的結果都要兼顧着作出來，要有前瞻性的眼光，顧大局。