背景

最近這一段日子，絕大部分時間花在一個答題系統上，項目預期是利用掃描儀獲取到試卷的數據，隨後對數據進行處理以及匹配規則，最終算出該題目的正確答案。目前系統已經開發到第二版本，現在還僅僅是一個簡易型的Demo，但是其中涉及到一部分坑以及在工作的時候發現的一些問題，鑒於此，使用文本記錄下來，為以後成為優秀程序員鋪路搭橋。

首先說一下數據，數據是由做底層算法的同事提供的，使用XML格式存儲，絕大部分數學公式都是Latex格式。我所做的事情，其實很簡單，就是將數據保存起來，同時提供數據配合前端。但真的有這麽簡單嗎？？？

第一版

在第一版中快速開發，直接將提供的XML格式原封不懂的保存到Mongodb中，然後提供查看的數據的接口給前端的同時，由前端展示題目。同時再提供一個接口，用於接收前端傳來xml格式，將xml作為參數調用有算法小組提供的jar，最後獲取到題目計算結果反饋給前端。其實就相當於數據的搬運工....

開發異常簡單，接口不多，又不用處理....So？快速開發，解決掉項目，然後轉戰別的工作。但是在前端人員開發的過程中，這樣的後臺設計暴露出越來越多的問題。For example：

• 前端展示題目需要獲取到題目的文本信息，並不需要xml中的標簽，於是乎前端開始解析Xml，大量的xml解析必定是消耗資源的....，同時文本中也存在一些影響展示的信息，因此前端需要最數據進行處理。
• 題目分成三種類型，選擇、填空以及簡答，前端需要識別題目歸屬於那種類型的題目，然後才能合理的展示題目(因為不同的類型題目，展示風格會不同)
• 由於項目不僅可以計算預先設定的題目，還可以在原題目的基礎上修改題目內容，因此前端使用一個插件來展示和修改題目(主要是公式的latex的展示和修改)，這個公式編輯器有些坑，不識別我們這邊的很多latex。
• 在前端開始解答事件被觸發時，需要後臺實時傳遞題意分析結果，用於展示在前端，提供一個良好的人機交互(主要讓使用者知道，我們的系統在計算， 而不是死機...)，這個地方一開始為了快速開發，也是采用比較low的方法，沒錯！！！就是AJAX輪詢...輪詢的各種弊端，我就不多做闡述了，各位腦補吧

第二版

由於第一版出現的各種問題，在第二版中做了很多改進，改進如下：

• xml數據的處理從前端移交到後臺，使用python腳本預先處理好xml數據，然後按照不同的數據格式保存到Mongodb中(根據題目類型的不同而不同)
• 由於一開始使用的開源Latex公式編輯器並不適應算法小組的Latex，因此經過調研以及各位領導的努力，我拿到了一個團隊基於這個公式編輯器開發的絕大部分適應算法小組的Latex格式。
• 將原先使用AJAX輪詢實現實時前後端同步數據，改成使用webSocket(這部分邏輯有些長，下篇博客會主要講一下這部分)

整個項目是基於Spring boot框架與Jetty服務器的，使用這個Spring boot框架的目的有兩個

• 快速開發，不需要過多的配置
• webSocket 與 Spring boot 配合很好
• 以前沒用過這個框架，而它又很火，So？我心裏癢癢的，於是就開始了任性...(其實使用Jetty的目的也是因為這個原因)

坑與解決辦法

• 算法小組提供的數據存在數據有誤、格式不統一等等。
  • 解決辦法：
    • 在編寫python代碼時，多考慮可能會出現的錯誤，做好容錯以及發現錯誤之後，對錯誤的定位。
  • 具體實施：
    • 對於文件格式不符合要求的，會拋出異常，捕獲異常之後，打印到控制臺。
    • 對於xml格式不正確(由於是數學公式，因此存在<,>符號，而這些在xml中是不允許出現的)，在解析之前先進行一層過濾，將不符合xml規範的數據規範化，然後在調用xml解析程序，解析完成後處理再保存。
• 新的公式編輯器雖然比老版本的兼容性要高，但是還是存在很多不兼容問題，這不僅僅影響展示，更加影響計算過程(算法小組所需的Latex與公式編輯器生成的不一致)
  • 解決辦法：
    • 在公式編輯器利用Latex生成公式圖片之前，進行Latex的處理(為什麽不直接在解析xml的時候處理呢？因為...我盡最大可能不改變算法小組所需的Latex格式，如果使用者沒有對原來的題目進行修改，直接答題，會將原先的Latex傳遞給計算模塊，這樣可能保證計算模塊所需數據的正確性)
    • 在傳遞給計算模塊之前還有一層公式轉換器，會將那些不符合計算模塊的Latex修改成符合計算模塊的Latex
  • 具體實施：
    • 基於這兩層處理層，基本上可以保證計算模塊所需數據的正確性
    • 使用各種正則表達式替換和處理(很鍛煉正則的能力)
• ....(還有很多小坑，就不詳細說了，絕大部分都是自己那菜鳥級的經驗)

項目現版本存在的問題：

• 前端單個頁面承擔太多的展示任務，導致CSS與Js文件臃腫且bug層出不窮。
• 算法小組提供的數據有很多錯誤，在同一個文件中描述同一個公式卻使用不同的Latex公式，讓我這邊適應很困難，因為不知道到時候真正需要計算的Latex具體格式，如果傳遞有偏差，計算模塊是否可以能解題
• 系統在相隔一段時間沒有人訪問之後，再次訪問會莫名其妙的報Mongodb time out錯誤，解決了好幾次，都以為自己解決了，但是...bug還是一致存在(間斷性)

感悟

• 項目在一開始的需求步驟和第一版的開發前中期我都沒有參與，導致對需求的不理解與項目整體把握程度不夠，不能做到很好的協調。個人認為無論開發什麽項目都應該將大家聚在一起，一起討論需求，一起規定我們要做出什麽模樣的產品，而不是一個人在想，另外一幫人在等著被安排，凡事應當主動，主動參與到項目的需求討論中。這樣不僅能提高項目的整體質量，而且也能提升個人能力以及對項目的把握程度！
• 跨部門的合作成本過高，一定在開發之前約定好數據格式！！！編寫維護好開發文檔！！！
• 寫代碼之前要先設計，沒有思路就不要動手寫代碼，項目要的是高水準的代碼，而不是一坨坨...

最後很感激部門領導給我這次機會，讓我開發並協調各開發人員，這是對我的鍛煉，雖然辛苦和煩惱，但是對於個人能力的提升有很大幫助。

答題系統項目總結