[2019BUAA軟件工程]結對編程感想

結對編程感想

寫在前面

  本博客爲筆者在完成軟件工程結對編程任務後對於編程過程、最終得分的一些感想與經驗分享。此外筆者還對於本課程的結對編程部分提出了一些建議。

Tips	Link
做業要求博客	2019年軟件工程基礎-結對項目做業
筆者的總結博客	[2019BUAA軟件工程]結對做業

---

對結對編程過程的感想

  通過長達兩週的結對編程，結合《構建之法》中對結對編程的描述以及這兩週的親身經歷，筆者對於結對編程的過程有了如下的感想。

• 兩人合做，更易解決問題
    在編程的過程當中，筆者兩人一同遇到了許多的困難：從編程語言的使用，到算法的設計，再到代碼的實現。相較於單人編程，兩人同時對問題進行思考，經過討論發現兩人解決問題的漏洞，互補雙方解決問題的方法，有效地解決問題。好比，在筆者同夥伴一塊兒編寫單詞鏈搜索函數時對於每一個代碼分支，遞歸調用都進行了相似一人推演一人審覈的模式，有效地突破了程序中的難點。

• 相互學習，共同進步
    在進行結對編程時，每人都有一段時間負責在對方編程的過程當中在旁邊進行審覈。在「旁審」隊友編程的過程當中，筆者從隊友的編程方式吸收了許多有用的部分，好比算法實現的思路，代碼編寫習慣等。將這些優勢融入到本身的編程中，優化了本身的編程方式。

• 同時編程，下降溝通難度
    結對編程要求兩人同時在一塊兒進行開發。筆者與隊友在大多數時間裏是按照結對編程的要求一同編程。很明顯能感受到，本身很熟悉在這段時間的編寫的代碼，即便是對方在掌控鍵盤編寫。在必定程度上，減小了兩人閱讀對方代碼，詢問如何使用對方代碼時消耗的時間。相較之下，程序有一部分代碼並非兩人一塊兒編寫的，在使用僅由對方編寫的代碼時常會產生許多的疑惑，須要在溝通上花費很多的時間。

• 時間規劃上存在難度
    結對開發的兩人並非一直可以抽出時間一同編程。時間的碎片化也增長了兩人一同使用大塊時間進行編程的難度。就筆者兩人而言，在這兩週中基本上只有晚上有可能同時有時間結對編程。而白天經常會是一人有空而另外一人有事的狀況。於是結對編程時，對於時間上的規劃存在必定的難度。可是若是是在相似於公司的環境中進行結對編程，這個問題應當會減輕不少。

• 工程量較大時，進度較難推動
    結對編程和分工開發就比如單線程與多線程。當任務的工做量較大，而且各模塊的開發任務能分解爲並行度較高的子任務的時候，很明顯進行分工「多線程」開發的效率會高一些。再基於上一條，在面對工做量較大的任務，結對編程頗有可能會在推動開發進度上出現困難。在筆者結對編程的前期，兩人編程的效率是比較可觀的，很快就完成了基本功能。但隨之而來的測試、優化、迴歸測試、GUI繪製等等任務使得原本時間就不太富裕的結對編程出現的進度推動上的困難。最終筆者兩人將部分任務的任務進行了分工開發，緩解結對任務的壓力。

---

對最終成績的感想

重要的不僅有代碼

  實話說，對於本身最後的得分可以位於前列的事情我是十分驚喜的。咱們編寫的程序在進行公共測試時的表現並不太理想，公測的最終得分在班級中應該是排在中間偏上的水準。但最終可以脫穎而出，主要靠的是博客部分的得分。在分析最終排名靠前的同窗的得分後，我發現你們在測試時的得分其實都差很少，只有少數小組在測試時取得了先當出色的成績。這說明你們在解決問題時所採用的方法以及最終的取得效果其實都差很少。而最後拉開差距的則是博客部分的完成狀況。
  在開發的過程當中，不管怎麼強調代碼質量的重要性都是不爲過的，畢竟代碼質量是一個項目的根本。但除此以外，開發的其餘環節也不該當被忽視。好比說，開發中各類文檔的編寫。在筆者進行結對編程時完成的而總結博客就至關於從宏觀角度對整個開發流程的總結和反思。筆者在進行結對編程工做的同時就已經開始了博客的撰寫。每過一段時間就會對博客中的一些內容進行更新。在寫博客的過程當中，筆者可以對編程的過程進行必定的反思，使得編程工做的目標更爲明確。除此以外，在真正的開發流程中還有例如API文檔等「中間文檔」。這些文檔在開發過程當中起到了潤滑劑的做用，讓團隊中每個「齒輪」能緊密的咬合，使整個團隊可以正常地運做。固然，這些文檔的做用每每會體如今最終的代碼質量當中。

---

對於課程的建議

• 結對編程題目的改善
    本次結對編程的題目是解決最短單詞鏈問題，分爲有單詞環和無單詞環兩種狀況。根據課程組給出的做業要求，筆者認爲完成本題目的重點應當在與對算法的優化方面。在無單詞環的狀況，因爲英文字母數量的限制，搜索的複雜度並不大，不一樣搜索算法的差距不易體現。筆者在這一步分嘗試採起了深度搜索和動態規劃兩種方法來解決問題。最終兩種方法取得了相近的效果（肉眼不可見的差距）。
    在有單詞環的狀況，該問題至關於NP問題，而最終評測是要求程序給出肯定解。因而沒法採用啓發式算法解決問題，僅能經過優化肯定算法來提升性能。而這種方法帶來的效益是至關有限的。固然也有個別小組採起了至關有效的優化操做，但絕大部分組的優化效果甚微（包括筆者的小組）。筆者認爲該部分若改爲「在最短期內給出最長的單詞鏈」這樣的評判標準的話，你們就會在這一部分有更多的操做空間。
    除此以外，筆者認爲本次結對編程的題目缺乏必定的開放性。這主要體如今開發過程當中在用戶體驗等其餘方面缺乏設計的開放性，你們除了算法的方面幾乎沒有操做的餘地。而最後的程序評測也主要參考程序經過的測試點和性能，少了些程序其餘的方面的評價。

---

寫在後面

• 應課程組要求附上筆者「黃衫」照片：