前言

在上一個答題的專案中，被一個非常小的功能折騰了整整三天

當用戶在選擇題庫後，系統隨機從後臺返回20道題目由使用者作答，程式碼如下：

queryMultiQuestionBank.find({
      success: function (results) {
        console.log("共查詢到 " + results.length + " 條記錄");
        for (var i = 0; i < results.length; i++) {
          multiQuestionList.push(results[i])
        }
        var newMultiQuestionList = that.getRandomSingleChoice(multiQuestionList, 20)
        for(i=0;i<20;i++){
          newMultiQuestionList[i].attributes.userChose = "空";
        }
        that.setData({
          newMultiQuestionList: newMultiQuestionList,
          loading:false
        });
      },
      error: function (error) {
        console.log("查詢失敗: " + error.code + " " + error.message);
      }
    });
 

其中我將隨機選中的每道題的.userChose屬性定義為空，而在使用者每答一道題時，就會將此屬性賦值為使用者的選項，從而和正確答案進行判斷使用者的對錯和得分。

具體的邏輯就是 使用者選擇題庫 → 進入作答頁面（後臺返回相應題庫的隨機20道題）→ 解答第一道題（將物件陣列中第一個物件的.userChose賦值）→ 自動跳轉至第二道題（並在跳轉的過程中將更改過的包含20道題目的物件陣列傳至下一題）→ 解答第二道題（將物件陣列中第而個物件的.userChose賦值）…….

最終答題結束進入交卷頁面，系統對比使用者每道題的選項和答案從而判卷。

思考過程

作為corder的你看到這一邏輯，第一時間會想到其中的難點就是對包含20道題的物件陣列進行處理及傳遞，經過我的入坑填坑，共有三種方式實現小程式中跨頁面傳遞物件陣列

1.由頁面跳轉事件傳參

2.將每次進行過更改的物件陣列均上傳至伺服器，然後進入下一頁面再由伺服器傳至本地

3.將物件陣列儲存到全域性變數中，一切操作均在全域性變數完成

首先大部分人按照正常的開發邏輯都會選擇第一種方式，我也不例外，但是當我輕鬆的寫完幾句程式碼編譯後才發現事情並沒有我想的那麼簡單…

wx.navigateTo({
      url: '../questionDetail/questionDetail?questionList=' + questionList
    });

解釋一下上句程式碼，在跳轉至questionDetail這個頁面時，將本頁面的questionList這一變數帶到下一頁面並賦值給questionList。

但是編譯後我在下一頁面並沒有接收到相應的資料，並且很坑的是編譯器居然不報錯，導致我剛開始花了大量時間排查，最終多次測試才發現問題出現在物件陣列這裡，小程式不支援這種傳遞物件陣列的方式。

於是我想到了更暴力的方式，物件陣列不支援，字串總支援吧，我在傳遞前將物件陣列用JSON.stringify方法轉成字串，並在下一個頁面接收到後再用JSON.parse轉回去。

但是編譯後依然不行，log下確實是成功的進行了格式轉換，但是就是重新整理不到頁面上去，於是這個方法也堵死了。

接著腦海裡閃過第二個方法，將資料放到伺服器處理，但是這一邪惡的想法立馬被pass，答題這種高頻的行為是，如果對資料進行服務端的存入取出那耗費的資源將遠大於放在臨時記憶體中。

正解

所以只能採取第三種方式，其實說實話第三種方式反而比第一種更省資源一些，至少在跳轉頁面時會更流暢。

globalData: { 
    singleChoiceAnswerNow:[],
    multiChoiceAnswerNow: [],
  }

 getApp().globalData.singleChoiceAnswerNow = that.data.questionList;

然後在做答完後將物件陣列賦值給全域性變數。

總結

其實程式碼寫多了，拿到一個需求後基本上大腦就可以條件反射出一種以上的實現方法。

初級程式設計師的職業素養分三級，第一級是想到第一個辦法就網上擼程式碼，什麼時間複雜度都不管實現功能就行；

第二級是用最簡單的方法實現功能，這裡的簡單是針對於自己的，例如剛才提到的第二種解決辦法，功能實現，自己寫著舒服就行不管使用者用著難不難受。

第三級是至少羅列出三種以上的實現方法，並逐條分析其資源佔用、時間複雜度、程式碼量以及使用者體驗等等因素，從中選擇出最適宜的方法去實現。

這也就是我一直的理念，產品經理可以不會但是不能不懂技術，軟體開發的一個各階段相互緊密交織的流程，是不能絕對的說“精細化分工效率更高”的。

產品和程式設計師撕逼的最大原因就是產品把需求全部下沉到技術那裡。

求打賞個早飯錢~