相較于個人專案著重培養獨立解決問題的能力而言，結對編程提供了一個共同進步的機會，通過分析對方的代碼，我們可以經由對方的優點而見賢思齊，可以經由對方的不足而互助共勉，現在，我想談一談我對志豪同學工程檔案優缺點的理解，
我認為，實作需求是軟體開發的第一步，在這一點上志豪同學幾近完美，他不僅僅是實作了邏輯層面上的出題功能，也沒有滿足于不夠便利的命令列輸入，而是做出了友好度更高、可用性更好的圖形用戶界面，密碼輸入時做暗文處理、切換型別時按鈕“三選一”、一鍵切換賬號、“生成試卷”按鈕提示試卷型別、Console同步輸出、使用相對檔案夾輸出txt檔案，這些細節無一不體現出他的設計之用心，也正因于此，軟體的使用體驗很是出色，金無足赤，我認為如果生成試卷之后程式能夠彈框提示，那么會更加完美，txt檔案中題目沒有標明題號，也是一個小小的不足，
談完使用體驗，現在回到代碼本身，我認為代碼所體現的面向物件的編程思想很值得學習，用不同的類分別表示登錄視窗、賬號匹配功能、出題功能、出題視窗與型別切換視窗，通過創建物件、事件處理、方法呼叫等方式實作功能之間的切換，這是非常棒的設計理念，GUI各類組件的合理使用與呼叫同樣體現了設計者設計之巧妙，程式中的例外處理體現出設計者扎實的Java編程基礎，很慚愧，我沒有設計圖形用戶界面，而是在代碼美化、性能優化上多下了一些功夫，所以我或許更能注意到一些細節并提出一些改進建議，希望共同學習進步，取長補短，力爭在接下來的結對編程中設計出更加出色的專案，
對《Java編程思想》的研讀幫助我養成了比較規范命名習慣，習慣上類的首字母大寫，變數與方法的首字母小寫，輔以駝峰式命名法，即用大寫字母標記每一個邏輯斷點，盡量取有意義的名字，比方說實作賬號匹配功能的類我更傾向于取名“AccountsMatch”，實作出題功能的函式我更傾向于命名為“setQuestion”，此外，我認為僅處理error而不去重視warning是一個比較不好的編程習慣，考慮到代碼中仍未處理的warning大多是一些無用的import，我更推薦刪去這些import，同時，我建議在代碼中添加更多注釋以增加可讀性，這樣在結對編程時會更加順利，除此之外便是一些演算法與資料結構上的完善，比如，在出題功能的實作程序中，我更推薦使用陣列存盤運算子，出題時取亂數作為索引會更加方便，
希望我們能在結對編程的學習程序中相互學習、共同進步，志豪同學編程習慣上的優點與出色的邏輯思維能力值得我認真學習，我也會不吝自己所學，提供最用心的建議，加油！
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/3073.html
標籤：面向對象
上一篇：Java基礎語法（總結篇）
下一篇：uml統一建模語言學習筆記(一)