結對編程の優缺點
【剛剛結束結對編程之初體驗,來此彙報一下,順便領雞腿。】前端
AssertTrue((大神·王若愚 && 渣渣·李雲濤).CompleteProject)算法
所謂結對編程,簡單來講就是兩個程序猿坐在一臺電腦前面,一個手扶鍵盤手指飛速移動,一個沉思狀在一旁默默盯着電腦屏幕不時還稍微吐槽幾句。就像下面這張圖片這樣編程
那麼問題來了。碼字的不想被不幹活的指點,吐槽的又看不慣對方的作法,這種情形在初期尤爲明顯。所以,結對編程的缺點在前期表現的很是明顯,如:後端
由代碼規範之類的小問題激化出較大矛盾。性能
編碼過程當中出現意外的交流話題,致使跑題。單元測試
兩猿都但願本身按照本身的想法作,因而產生矛盾,合做分裂,項目不能完成(,得不到工資,進入惡性循環)。學習
一個鍵盤直接致使碼字效率減半,開發時間變長。測試
某猿能夠以沉思猿的身份濫竽充數,不執行領航猿的工做。編碼
編碼過程當中身後存在奇特生物監視,瘮的慌。特別當奇特生物具備較長時間的生存經驗時尤爲嚴重。spa
......
這些問題或多或少會影響到開發效率。可是習慣這種開發方式、工程進行到後期時,會發現結對編程帶的優點是很是大的:
最重要的一點是:代碼質量高了不少!!!一隻寫一隻看的模式杜絕了不少小錯誤的出現,而這些小錯誤經常是很難發現卻相當重要的(好比分數中比較大小的負數問題)。後期調試時間大大縮短。
呆馬質量提升,全部編碼規範都能被有效執行,尤爲堅定杜絕Tab空格混用的狀況。
兩隻程序猿能夠在本身擅長的領域發揮強大的編碼能力,如一隻碼算法,一隻碼界面。
遇到困難問題有兩個腦殼考慮,效率高。
因而通過了一段時間的結對編程,讓我來點評一下渣渣程序猿(我)和大神攻城獅(隊友)
渣渣:
顧名思義,很是渣,因而鍛煉出了靜下心來碼程序的技能。能夠連續碼程序好久並屏蔽外界中斷和系統調用。
顧名思義,很是渣,所以爲了不錯誤反而會注重代碼中的規範,會嚴格遵照。
顧名思義,很是渣,因而常常學習各類東西,致使各類東西都聽過一點。
顧名思義,很是渣,因此常常會犯很小的錯誤,並且不容易發現。
大神:
顧名思義,很是神,各類高端算法直接默寫。
顧名思義,很是神,神速發現代碼中出現的各類Bug。
顧名思義,很是神,讀代碼能力很強,渣渣的各類奇葩代碼一遍讀懂。
顧名思義,很是神,神到不在乎某些細節,如變量名的選擇、代碼規範的統一。
因而渣渣此次幸運的在大神的幫助下完成了這次任務,就像這樣。
設計方法及實踐
Information Hiding:
信息隱藏,隱藏調用者不須要知道的信息,並拒絕用戶訪問不該被直接訪問的信息。
實現方法:全部類成員變量定義爲private,操做類成員必須經過調用相應的方法。對類使用額外的接口層進行封裝,只能經過接口調用到類內部。本次實現中所有對象均只提供方法調用,不提供直接的訪問權限,全部功能被封裝在一個大的接口下。
Interface design:
接口設計,應儘可能簡單、清晰,調用者很容易經過接口瞭解到相應的功能。
實現方法:選取合適的命名,給合適的參數和參數名。在命名時應按照規範進行。
Loose coupling:
鬆耦合,即減小模塊與模塊之間相互依賴的關係。當雙方中的一方改變時,另外一方無需變更功能照常。
實現方法:面向對象的思想就是鬆耦合的一個體現。對象封裝屬於本身的數據和操做方法,供外部調用的只有方法而沒有直接的數據。全部接口一旦定義好功能再也不修改,每次修改代碼不能對輸入要求更嚴,可是能夠更鬆,輸出應相同,產生的反作用能夠更少但不能更多。本次程序功能模塊與用戶界面實現鬆耦合,核心利用接口層接收用戶輸入的參數,傳入到相應的模塊進行處理,返回處理結果。前端無需知道後端的實現方式。
單元測試
對於本次程序,使用了單元測試以確認每一個部分是否正確。以下圖所示。其中每一個測試針對功能中的一個模塊,測試了不一樣分支路線的處理狀況。
核心模塊類關係UML圖
BasicNum類實現了一些基本數據類型的高級運算功能。
Number類用於記錄算式中出現的數,提供了分數的多種方式建立、存儲、運算以及按格式輸出功能。
Formula類記錄多項式,內部的數爲Number類對象,提供隨機生成功能,能夠設置參數。
Program類爲頂層接口類,將全部功能封裝爲統一的接口模式。
在實現中使用了一些小的技巧。
對於數字的存儲,不管輸入是分數或是小數,均使用了假分數的形式(小數化爲分數),這樣在處理時能夠統一。重載輸出方法,知足各類格式的輸出需求。
算式的生成模擬後綴表達式的運算過程,括號爲邏輯添加而不是人工隨機添加。
隨機生成數字和算式均有參數控制,做爲各自類的方法而存在。
對於極端參數,如太小的最大數值和過大的生成數量,程序斷定爲:連續生成50個均失敗即爲參數不合法。此閾值能夠根據性能需求方便修改。