結對編程 By：李暢&李雅楠

開始、結束與開始

by李暢 李雅楠

 

看似漫長實則短暫的結對編程項目就這麼結束了。細細回想起來，其中更有着點滴的感悟與體會。那麼，讓咱們一切從頭提及，慢慢回味其中的點滴。

 

Part 1

 

初遇結對編程，對其中的點滴真的是能夠說徹底不瞭解。結對編程？如何去作？怎麼去作？又會有什麼結果？一切，起於未知。

 

而在從我的項目到結對編程項目轉換的初始，就開始體會到結對編程項目的細微好處了。首先是相互之間的互看代碼。（先例行感慨一下本身的搭檔真的很厲害）在互看代碼的過程當中，咱們開始瞭解對方的思路，開始明確對方的想法與解題方法。有的地方，咱們不謀而合，有的地方，她更勝一籌，有的地方，我可能有些特點，有的地方，咱們都互有缺陷……沒有人的代碼生來完美，也沒有人的代碼一處不錯，咱們都互有優缺點，咱們都互有須要學習和能夠被學習的地方……咱們，互相在學習與探討中成長。

 

瞭解搭檔代碼的過程，對本身有着很好的提高做用。之於我，在理解的過程當中明白了本身的不足，明白了本身對需求理解的不透徹，也明白了不一樣人對於同一需求的不一樣理解……在這個過程當中，我明白了不少。而這一切，不過是結對編程初起步。咱們纔剛剛開始。

 

Part 2

 

代碼的開啓，源於一個詞——複用。（今天我就要瘋狂吹我搭檔）搭檔的我的項目代碼幾近完美，至少從功能實現上來講，她對功能實現的解讀對我真的是啓發很大。並且她代碼的擴展性很強，在我的項目中她就已經作出來了界面，再者針對後續操做更能看出她代碼的可擴展性，因此咱們以搭檔的代碼做爲複用基礎。而在複用的過程當中，咱們也認識到分模塊編寫代碼及簡約一個函數中包含內容的重要性與必要性。

 

代碼複用，簡單來講就是，你把一個功能寫成一個模塊， 以便當再次須要相同功能的時候，能夠直接使用，而不用從新開發。函數，繼承等，大抵都是運用了這種思想。而代碼重用，也是面向對象編程的一個突出部分，固然，亦是面向對象與面向過程兩種編程的不一樣所在。

 

 

我是一條分割線

---

​

隊友這樣商業互吹式的開頭就讓我很尷尬了QAQ只能尷尬地迅速轉移到正題。

 

首先談談隊友說到的代碼複用，或許是出於當過PM的直覺吧，我的項目沒有要求語言，需求中也是說的使用命令行完成指令，我仍是默默給本身加了需求，作了界面，也選擇了可移植性更強的JAVA語言，所以代碼複用的底層工程，我和室友不謀而合地拍板定了個人項目。其實在代碼複用方面，結對編程的第一項任務——互看代碼，對我幫助很是大。雖然和隊友用的不是同一種語言，但思想上是相通的。每個功能都封裝成了一個函數，只有在主函數中，按照流程依次調用了各個功能函數，其他函數之間幾乎沒有相互調用，基本作到了模塊與模塊之間，儘量的獨立存在。這一點也是個人代碼作的不太好的一點，爲了開發時省事，我將功能劃分的比較大，每一個實現子功能的函數都相對複雜，這樣一來，一旦某一個小功能需求改變，就須要在一個大模塊中調整，工做量會增大、出錯率也會提升。室友的實現方式遵循了高內聚、低耦合原則，正是咱們考慮代碼複用時的基準原則。代碼複用還體如今可擴展性和程序智能化方面，以我的項目需求爲例，需求中說，「每一個帳號一個文件夾」，我當時是按照用戶文件夾提早建立好，而後生成試卷後尋址，存入該文件夾來理解的。而她的代碼思路我以爲更好，在準備生成第一套試卷時，若用戶文件夾不存在，則建立，這樣一來擴展性比較強，當用戶增多，或者需求改爲用戶表不是預設好的，而是經過註冊產生的時，就會容易實現得多。這都是我在隊友代碼中學到並用在告終對編程中的。

 

Part 3

 

簡單介紹一下程序開發的細節。

 

---

 

​ 開發環境：Eclipse+Tomcat-7.0.85

開發語言：Servlet+HTML+CSS+JS+MySQL+Ajax

 

---

​

底層是由Servlet開發的，我通俗地理解了一下，就是將實現了servlet接口的Java類，部署到web服務器中。

處理HTTP請求的方式是HttpServlet。若是爲GET請求，則調用HttpServlet的doGet方法，如爲Post請求，則調用doPost方法。

 

前端HTML+CSS+JS都是現學的，從界面排布到事件觸發，都走了很多彎路，即使是最後的代碼也是很是不專業的，並且沒有徹底實現需求文檔。因爲第一次接觸前端，我並無使用框架，一是以爲可能沒有那麼多時間再去了解各類框架，二是幾天速成的技能，本來基礎就沒打好，仍是但願能經過這份可能沒法作到完美的工程來對基本語法結構有所瞭解。

 

花費比較久時間的還有先後端的數據傳輸，這裏咱們選擇的是表單數據提交和HTTP請求。對網上大神代碼的研究發現，Ajax或許是最爲優秀的方法，可是Ajax技術所關聯的知識點很是普遍，若是瞭解不夠深刻，設計起來也會有難度，所以最終權衡之下，仍是給早就訂好的假期旅行留了點時間（言外之意：少學了點）。

真正實現的過程當中，表單數據提交仍是帶來了必定困難的，Servlet層只能向HTML請求表單數據、以及直接打印到HTML界面，並不能傳遞單個表單數據給HTML，所以出現了開發過程當中與需求文檔最大的出入——答題界面，答題界面本來答案提交表單和題目應當在一塊兒的，結果我想了好久仍是沒找到不使用Ajax通訊，將數據傳輸給瀏覽器的方法，只能按照反人類邏輯先作出來了，僞裝本身堅持了敏捷開發、屢次迭代的原則，嗯！

 

比起沒接觸過的前端，後端的實現相對容易了很多，不作數據庫，就只剩了出題算法、post請求發送驗證碼。這裏簡單介紹一下出題算法，以前的算法雖然出題邏輯都實現了，可是計算起來很困難，因而重構了一下這個算法，考慮到括號和運算符優先級之餘，也在出題過程當中將結果一步一步算了出來。

算法簡述： 一、題目在生成的過程當中運算出結果，主要思路爲分治思想：若子運算式兩邊帶括號，則直接看作一個總體求解出運算結果，每一個小總體都遵循從左到右，先乘除後加減的算法。

二、算法改進：在我的項目的基礎上考慮了乘除法優先級高於加減法的現實狀況，只有內部運算符含有加減時纔會出現括號。

三、對題目嚴謹性的考慮，平方和根號運算符較難生成，所以用^2和^0.5代替，因爲括號的存在，容易產生歧義，所以本版本將^2和^0.5的做用域用括號表示；

四、考慮題目人性化問題，將初中難度和高中難度的運算符出現頻率都=相應下調。

五、以小學題目生成的實現爲例：先生成n(2-5)個操做數，放入列表中，從中任取兩個加符號和括號，再將取出的兩個對象當作總體，從新放入列表中作前一步操做，直到全部操做數稱爲一個總體在合併的過程當中將括號內的結果算出，最後的運算只需調用Result類的簡單運算函數（遵循先左後右、先加後減原則）便可完成。中學題目只需在運算子式上添加相應的2、三級運算符便可。

 

由於我的項目作了簡單的UI界面，所以結對項目就不想守着老本不放，因而選擇了Javaweb，但願能在強壓之下學到點東西（在這裏鬆口氣，國慶節在各個景點玩的時候還牽掛着咱們的項目，差點覺得要涼了）。其實這個項目仍是有必定記念意義的，由於是咱們動手作的第一個小型Javaweb工程，一切從0開始學。和以往一些紙老虎不一樣，網絡編程是聽起來很難，真正作起來也不容易的那種。首先須要設計各個功能如何實現，這就要知道咱們所選用的前端和後端語言都能實現什麼，能作到怎樣的通訊功能，所以除了複用以前代碼寫的純算法部分——題目生成和計算，國慶節的前幾天（雖然只有晚上）我都在瞭解這些語言，經過別人的工程案例，去推斷它們能作到什麼，本身能調用什麼。看着看着就感受要學的越看越多，因而咱們在懸崖邊及時收住了給本身不斷「完善」的需求，暫時放棄了數據庫，選擇了很low的文件存儲。

 

距離接近一千千米的結對編程，給咱們也帶來了必定的麻煩，由於我白天要出去玩耍，害得隊友明明回了家，還得大半夜和我「雲」結對。直到回來之後，咱們兩個坐在一塊兒debug才發現，極限編程是多麼的優秀，兩我的都有特別傻的邏輯，相互碰撞，就能恰好把bug碰掉了。

 

 

Part 4

 

迴歸根本，從頭至尾去回憶結對編程中的點滴，感受其中伴隨着茫然與收穫。做爲一個代碼能力較弱並且不善於使用API的人，在撰寫代碼的過程當中遇到了許多的困難，不少地方都是經過查找相關資料以及看網上的大神們寫的博客去一點點扣出來解決的，還有一部分是諮詢搭檔去進行解決理解的。面對細緻的項目需求和其中種種複雜的要求點，最初真的是茫然的，對Java語言的不熟悉，對HTML語言的不瞭解，對CSS，JavaScript語言的茫然，想要作出來一個基於網頁的系統，談何容易。從零起步，補充對應的知識，經過查找資料解決種種困難與難題。在短暫的時間內，要學習本身不瞭解的語言，一個項目組有許多的技術分工，兩我的又要去承擔其中的所有職位，從需求文檔，到設計網頁，從點點需求，到先後端撰寫。咱們走過了漫漫長路，初始之時，茫然相伴，結束之時，欣喜相隨。

 

Part 5

 

本次結對編程，有所收穫也是有所遺憾的，首先結對項目處於國慶假期，和搭檔天各一方分居兩地，相互之間進行交流與一些局部細節的處理等代碼上的問題，以及結對編程自己的意義都沒法獲得很好地施行與擴展，假期的特殊性致使兩我的沒法很好地完成結對編程的須要與意願，初衷沒有獲得良好的實現。其次，在存儲用戶註冊信息時，經過討論和查閱資料，大概得出了三種解決方式，第一，存儲到文件，第二，運用數據庫，第三，運用cookie的相關知識將其保存到瀏覽器。和搭檔針對三種不一樣的方案進行了探討，因爲數據庫的搭建較爲費時費事，且咱們剛開始數據庫的學習，對其中的操做不甚瞭解，因此這個最爲快捷有效且經常使用的方法只能忍痛割棄，而cookie的操做又過於麻煩，因而只能選擇很low的文件存儲。在文件存儲的過程當中，起初考慮建立指定路徑下的文件夾，自己有顧及到在IOS系統上運行的狀況（在咱們的助教小姐姐的提醒下忽然發現了還有Mac的狀況），可是在查閱資料發現說起的相關資料幾乎爲0，以及對Mac等電腦的不理解，致使對文件夾在Mac電腦上生成的代碼不夠明確，因此只能在根目錄下建立，文件存儲在相對路徑下而不是絕對路徑，存儲後的結果屬於理論上能夠存儲在電腦中，具體位置多是jdk的環境也多是處在編譯器所在的環境。對不一樣的電腦可能性不一樣，而且在編寫完代碼後沒有在Mac平臺上進行測試，也是存儲文件操做中的遺憾之處了。而在網頁設計中，咱們的網頁初始設計有7個頁面（分別是登陸界面，註冊中輸入手機號和接收驗證碼界面，註冊中輸入確認密碼界面，選擇題目類型界面，輸入題目數量界面，作題界面和顯示分數界面），可是在後期對網頁進行編碼以及連接先後端的過程當中，發現其中的一些問題，包括自己編碼者技術不夠成熟的狀況，最後爲了可以將其完美解決，不得不進行更改，與最初的需求文檔（見博客最後附件）的需求沒有徹底符合匹配。面對最後的網頁結果，雖然實現了需求，可是與最初設想不一樣，也算是在編程過程當中不完善的部分。

 

Part 6

 

然而，咱們依然在結對編程的過程當中學習了不少，補充了許多知識。而我也藉機和搭檔多多學習，從而掌握一些關於項目的更多知識。從需求文檔的詳細撰寫，到Axure RP的使用，再到CPP向JAVA的轉換，從用PS設計頁面與大體佈局，到運用HTML+CSS+JavaScript結合將它付諸實踐，從學習一些細微的編碼等，到考慮代碼規範性等狀況下對代碼格式與註釋格式的規範性，咱們經歷了不少，我也從中和網上的大神們，和本身的搭檔學習了不少。再者，咱們從入學起就瞭解到本身將來的種種就業方向，瞭解了一個項目組中的種種職位，可是對其的工做仍然沒有深入而基於實踐的瞭解，一樣，咱們從入學便知道項目經歷的重要性，可是本身參與其中的項目仍然是少數，就算加入了老師的實驗室，也每每是「打下手」的存在（固然，加入了一些社團組織的除外）。在此次結對編程的過程當中，咱們從頭開始，一切基於我的項目，或者對其進行擴展與重構，或者對其進行改寫，甚至重寫，可是咱們能夠詳細的瞭解其中的幾個研發的主要職位（測試方面尚未涉及），能夠基於實踐去加深瞭解與印象，真正的讓本身在「作中學」，爲本身將來的發展奠定。或許咱們將來的團隊項目會是一個更好的突破口，可是不得不認可，此次的我的項目，已經讓人感慨萬分，亦是讓人從中受益良多。或許我這句話在不遠的未來會被本身推翻，可是至少如今我堅信，這個項目會是我在大學期間經歷的項目中感觸最深，也會爲我留下最深入印象的一個項目。兩人之間的合做，相互之間的幫助，向對方不斷學習，在完成項目的過程當中不斷完善本身，或許這個是一個結尾，可是這個項目也是一個開始，或許它的初衷很簡單，可是在實現的過程當中咱們收穫良多，體悟頗深。

 

 

附：需求文檔（長圖版本）