結對項目解讀-隊友代碼解析

既然是兩兩一組天然是找室友搭檔是最方便的了。因而在看到結對編程的時候就已經和室友商量好要搭檔合做了。（固然也是爲了抱住大腿）

在語言方面，搭檔用的是Java語言，而我用的是C++，兩我的所用語言不一樣，可是在結對編程的要求中要求作頁面，一對比就很明確知道仍是要靠搭檔了。因此也主要分析一下搭檔的代碼方便後期結對編程在她的代碼基礎上進行更改提升。

 

首先是一個自我反思的過程，經過對她的代碼的解讀發現不少需求是我覺得我完成了實際上我並無成功達成需求。並且不少狀況的產生不夠隨機，仍是有些尷尬的。代碼表面上顯示的彷彿是都作到了，也隨機出題隨機產生了，可是相比較腦內活動，仍是有不少狀況不在考慮範圍內的。而她的實現就比較徹底了，在分析她的代碼的時候仍是比較有感覺的。

 

那麼，接下來就是主要針對她的代碼的解析了。

 

---

 

 

首先，在閱讀搭檔的代碼時有幾點建議，感受這個是她作的不是很完善的地方（固然，我也在這幾點中有作的不完善的狀況）。

1. 1. 她在生成文本文檔時，沒有生成文件夾的操做，而是直接在主函數中肯定了路徑而後存入。也就是說若是我沒有預先爲每一個老師設置好文件夾的話這個就會報錯。在這個方面程序的擴展性不夠。

      1.  1 public class AutoQuizSystem {
          2 
          3     /**
          4      * 當前用戶的存儲路徑 path
          5      */
          6     // 需根據實際狀況修改路徑
          7     static String path = "D:\\hi girl\\湖大\\做業\\大三上\\軟件工程導論\\1班-李暢\\1班-李暢\\Quiz\\";
          8 
          9     public static void main(String[] args) {
         10         // TODO Auto-generated method stub
         11         /**
         12          * 運行程序，用戶登陸。
         13          */
         14         new Login();
         15     }
         16 
         17 }

         可是，她這裏包含建立文件操做。咱們能夠在後期對代碼進行修改時經過查閱資料等方式，將文件夾也由代碼建立出來。

      2.  1 String fileName = now.get(Calendar.YEAR) + "-" + (now.get(Calendar.MONTH) + 1) + "-"
          2                 + now.get(Calendar.DAY_OF_MONTH) + "-" + now.get(Calendar.HOUR_OF_DAY) + "-" + now.get(Calendar.MINUTE)
          3                 + "-" + now.get(Calendar.SECOND) + ".txt";
          4 
          5         /**
          6          * 建立新文件，用於存儲題目
          7          */
          8         File file = new File(AutoQuizSystem.path + Login.name[Login.i], fileName);
          9         if (!file.exists()) {
         10             try {
         11                 file.createNewFile();
         12             } catch (IOException e) {
         13                 e.printStackTrace();
         14             }
         15         }

          

   2. 她在運算時首先判斷這個的密碼是不是123，也就是將登錄密碼所有設置爲123，沒有考慮更多其他狀況。雖然是因爲老師所給的需求文檔裏全部人的密碼狀況都是123，可是這樣子的設置在後期設置中會致使不少問題，也加大了對代碼的修改程度，是否能夠運用容器等，姓名和密碼分別處於一個容器，而後容器的初始長度相同，在加入的途中判斷存儲姓名的容器中對應的名字和存儲密碼的容器中對應的密碼是否相互匹配。（固然，我在設置時是直接運算的，也就是直接用判斷語句生成的 PS：在和她探討的過程當中有了新的想法，也許咱們能夠用一個類存儲用戶名和密碼，而後用容器存儲這個類。也是一個方案。

      1. 1 if (psw.equals("123")) { //type表示當前用戶的等級，name中存儲9個教師狀況
         2                     for (i = 0; i < 9; i++) {
         3                         if (usr.equals(name[i])) {
         4                             if (i < 3)
         5                                 type = "小學";
         6                             else if (i < 6)
         7                                 type = "初中";
         8                             else
         9                                 type = "高中";

          

   3. 搭檔的代碼功能基本都可以實現，可是有一個問題，就是她的註釋不是不少，對每個功能的註釋也不是很明確。寥寥幾處註釋，主要是介紹了這個函數的功能等，具備針對性的註釋不是不少。可是卻也有部分緣由，咱們後文細說~　　
   4. 在具體代碼方面，本次文檔所寫的需求較多，須要的功能函數也比較全面，可是仔細看搭檔的函數會發現她的函數進行了合併——有一些功能比較簡單的函數就直接與其餘功能的函數合併了，在後期修改的過程當中較爲麻煩。

一律而論的話，搭檔的代碼大致狀況很好，可是在部分方面可擴展性不夠強。後期若是增添更多需求或者別的方案的話代碼的修改幅度較大。

 

---

 

 

固然，瑕不掩瑜。在學習搭檔代碼的過程當中仍是學到了不少也瞭解了不少的。

1. 1. 搭檔在編寫代碼時考慮較多，想法也比較全面。看到她直接作了界面就能夠感慨了。不愧是作了n次pm的人，果真很懂需求。固然，也感謝搭檔作了界面，按鍵等功能，在結對編程時就能夠有所依據，有必定基礎與打底了。
   2. 在寫代碼時，搭檔寫了幾個.java爲後綴的文件，不一樣的文件控制不一樣的窗口及功能，確實是感受到了其中的邏輯性與佈局的合理性。
   3. 接下來就是上文中留的懸念了，搭檔在寫代碼時註釋不是不少，可是運用了大量的Java自帶API，這樣也能夠大大提升代碼的可移植性。（就是對像我這種不是很熟悉API的人是一種折磨，爲了讀懂代碼須要查不少API的功能啥的）

       1 /**
       2      * 構造函數
       3      * 
       4      * 功能實現：生成登陸窗口（用戶名輸入、密碼輸入、登陸鍵）。
       5      */
       6     public Login() {
       7         setTitle("自動出題系統");
       8         setLayout(null);
       9         Container c = getContentPane();
      10         JLabel username = new JLabel("用戶名：");
      11         final JTextField un = new JTextField();
      12         JLabel password = new JLabel("密碼：");
      13         final JPasswordField pw = new JPasswordField();
      14         pw.setEchoChar('*');
      15         JButton login = new JButton("登陸");

       

   4. 在設置初高中出題過程當中，搭檔的隨機方案較好，在每一處設置隨機值，在其中安插一些須要的函數。而且設置每個功能塊的計數操做，若是從頭至尾沒有初中必備（開根或者平方）或高中必備（tan，sin，cos函數）操做，則在最後爲其隨機產生一個位置放入操做。這些方法都利於一些特殊狀況的操做。也正是我在最初所說，經過閱讀搭檔的代碼更能明確本身代碼的缺陷，找到本身代碼的不足。
   5. 用戶出題級別較爲多變。在每一次出題後用戶均可以從新選擇本身的出題類型。這樣子也方便用戶隨時更改本身須要的等級。這個設計也是比較讓我佩服的。我當時在分析這個需求的時候就比較懵逼，不太懂這個需求的具體意思，可是看完搭檔的代碼以及運算演示後更加感受本身對需求的理解不到位，在實現過程當中仍是有不少問題。

 

 

---

 

 

最後，在小小的分析以後固然是要總結一下這個結對編程中代碼複審過程的意義所在啦~

1. 1. 經過審覈搭檔的代碼，反而對本身的代碼更是一種反思，明確了本身在寫代碼過程當中的種種不足，也在分析對方代碼的過程當中明確了一些本身沒發現的不足之處與可改進之處
   2. 審覈對方的代碼，其實也是對本身代碼的一種審覈：她實現的功能我實現了嗎？她在這裏是這樣實現的，那我呢？咱們兩個的實現方式誰的更好一點？這些需求咱們的不一樣理解不一樣實現誰會更加貼近於用戶的需求？種種問題更是一種自我反思，在不斷地自我反思中咱們也會不斷進步。
   3. 三人行，必有我師焉。兩人前行，更能相互鼓勵共同前行。相互對比，共同討論，一個問題的解決方案會有不少，一我的或許只能想出來一點，兩我的一塊兒考慮可能就會想出一個更完美的解決方式策略。這也許就是結對的魅力所在。
   4. 搭檔之間相互diss，相互表揚，更能知道本身的不足，明確本身的優點所在，在將來的發展過程當中更能取己精華去己糟粕。這樣才能不斷進步不斷前行。
   5. 一樣也要感謝本身的搭檔啊，沒有他們的diss咱們可能都發現不了本身的一些失敗與不足（而後還自覺得本身是成功的，恩，好比我）。