1. 程式人生 > >第一次做APP介面開發過程總結

第一次做APP介面開發過程總結

關於平湖人社APP後臺開發總結

這是我第一次做聯合開發,對於多部門多人員合作開發專案我這個才畢業沒多久的新人菜鳥還是有很多挑戰與困難的,不過只有在實際專案開發中才能學到東西.話不多說,我們直奔主題.(忽略我使用英文標點符號,開發不易啊…)

APP後臺介面開發我總結出以下幾個部分:

  • 需求分析與整理
  • 分析業務需求涉及的模組功能與資料庫關聯表
  • 介面開發文件大致編寫並提交產品與APP開發人員
  • 儲存過程介面編寫
  • 儲存過程介面測試
  • APP端完成模組功能後聯合測試調整
  • 完成各項測試後上線正式版本

需求分析與整理

需求分析主要是我在現場與客戶協商探討分析大體上需要完成的功能和APP原型,然後整理後前期需求給產品經理,後產品過來與客戶再進行商討具體功能之類事宜.我主要是瞭解大體上要做的東西和業務系統之間的區別關聯,方便日後去參考業務系統判斷編寫規則.這期間我就要準備相關的介面編寫事宜了,大體的介面編寫我其實是不瞭解的,之前都沒接觸過,之後一點一點的詢問專案經理,好在專案經理跟我說之前其他專案組曾今做個介面開發的模板我可以去借鑑下.這就我開始介面開發的準備了.

分析業務需求涉及的模組功能與資料庫關聯表

在產品經理整理好需求文件和APP原型圖發於我後開始分析自己要完成的任務有哪些 需求文件截圖
這裡我就取APP中最主要的功能模組–人員續保做例項.
這個功能主要是用於人員續保操作,其中涉及的資料表結構多,判斷規則多,完成難度大.當然也是我花費時間最多的功能了. 主要很多續保的規則我通過業務系統程式碼來看也是不夠的,好在客戶理解續保的麻煩跟我很細緻的解說並在後續開發測試中不予餘力的提供幫助,非常感謝他們.在完成續保需求分析後,我先不急著編寫介面,主要是現在寫也寫不好,必須要先進行介面功能UML建模(其實是之前的介面編寫吃過虧,沒有細緻分析判斷規則導致程式碼十分臃腫,不易於閱讀理解…)所以建模很重要!!!有助於理解複雜關係判斷.

部分判斷流程圖:

Created with Raphaël 2.1.2開始續保校驗人員單位資訊/基數範圍/險種類型...是否符合判斷規則?校驗參保單位參保情況/工傷生育可多單位參保是否符合判斷規則?校驗靈活人員單工傷/特殊企業不可參保是否符合判斷規則?插入資料庫資料是否插入成功?續保成功yesnoyesnoyesnoyesno

介面開發文件大致編寫並提交產品與APP開發人員

介面開發文件以前也是沒有寫過的,難以下筆啊.一樣是詢問專案經理完成的…

2.介面函式統一為 sbp_sbcx_XXXX

3.傳入引數: 傳入引數全為Stirng型別,格式為json字串,基本格式為(傳出類似不列出):

欄位名稱 型別 可否為空 欄位說明
jhjd string 交換節點
sbbh string 社保編碼
certno string 身份證號
jylx string 交易型別

json格式內容:{“jhjd”:”330482”,”sbbh”:”000001”,” certno “:”330425199009098787”,”jylx”:”1”}

4.資料字典 :對部分欄位進行補充示意

程式碼塊語法遵循標準plsql程式碼,貼出部分程式碼吧(也就是儲存過程編寫):

--1007人員續保申報
  Procedure sbp_sbcx_1007(as_inmsg in long, as_outmsg out clob) is

    al_inmsg      long;
    j_JsonmainIn  Json.Jsonstructobj; --主資訊JSON
    Ret_ErrCode   varchar2(10); --錯誤程式碼
    Ret_Errmsg    varchar2(32670); --提示資訊
    j_JsonmainOut Json.Jsonstructobj; --主資訊JSON
    j_Json        Json.Jsonstructobj; --主資訊JSON
    t_Array       Sbp_Public.t_Varchar2;
    iv_dwbm       varchar2(30);
    iv_sbbh       varchar2(30);
    iv_sfzh       varchar2(30);
    iv_xm         varchar2(30);
    iv_xb         varchar2(4);
    iv_csrq  varchar2(30); --出生日期        
    iv_hkxz  varchar2(30); --戶口性質        
    iv_lxdh  varchar2(30); --聯絡電話        
    iv_lxdz  varchar2(50);-- 聯絡地址        
    iv_ygxz  varchar2(30); --用工性質        
    iv_jfjs  varchar2(30);--繳費基數         
    iv_xbyy  varchar2(30); --續保原因   
 Begin
 Ret_ErrCode := 'B00';
    Ret_Errmsg  := null;
    --判斷傳入引數
    app_sjjc.P_Dissemble('1007','1',as_inmsg,Ret_ErrCode,Ret_Errmsg);
    if Ret_ErrCode = 'ERROR' then
      sbp_err(Ret_ErrCode, Ret_Errmsg, as_outmsg);
      Return;
    end if;
    ---解包
    al_inmsg := as_inmsg;
    ---轉換成json
    j_JsonmainIn := Json.String2json(al_inmsg, '"'); --轉換成JSON


    iv_dwbm := Json.Getattrvalue(j_JsonmainIn, 'dwbm'); --取得單位編碼;
    iv_sbbh := Json.Getattrvalue(j_JsonmainIn, 'sbbh'); --取得身份證號
    iv_sfzh := Json.Getattrvalue(j_JsonmainIn, 'zjhm'); --取得身份證號
    iv_xm   := Json.Getattrvalue(j_JsonmainIn, 'xm'); --取得姓名
    iv_csrq := Json.Getattrvalue(j_JsonmainIn, 'csrq');
    iv_hkxz := Json.Getattrvalue(j_JsonmainIn, 'hkxz');
    iv_lxdh := Json.Getattrvalue(j_JsonmainIn, 'lxdh');
    iv_lxdz := Json.Getattrvalue(j_JsonmainIn, 'lxdz');
    iv_ygxz := Json.Getattrvalue(j_JsonmainIn, 'ygxz');
    iv_jfjs := Json.Getattrvalue(j_JsonmainIn, 'jfjs');
    ......
    begin  

      select * into rec_ac01 from ac01 where aae135 = iv_sfzh;

      select aaz001 into v_aaz001 from ab01 where aab001 = iv_dwbm;
    exception
      when others then 
         Ret_ErrCode := 'ERROR';
         Ret_Errmsg  := '未找到人員資訊或單位資訊';
         sbp_err(Ret_ErrCode, Ret_Errmsg, as_outmsg);
         Return;
    end;  

    select aab019 into v_aab019 from ab01 where aab001 = iv_dwbm;
    if v_aab019 = '99' then
         Ret_ErrCode := 'ERROR';
         Ret_Errmsg  := '行業統籌型別單位不允許手機參保,請去社保中心辦理';
         sbp_err(Ret_ErrCode, Ret_Errmsg, as_outmsg);
         Return;
    end if;
    ......

    -- ac02 無資訊
       --插入ac21
        select sq_aaz308.nextval into rec_ac21.aaz308 from dual;
        rec_ac21.aaa027 := rec_ac01.aab301;
        rec_ac21.aac001 := nvl(i_aac001,rec_ac01.aac001); 
        rec_ac21.aae140 := v_cbxz; 
        rec_ac21.aae030 := n_aae002;
        rec_ac21.aic001 := 0; 
        rec_ac21.eac070 := '0';
        rec_ac21.aac033 := to_char(sysdate,'yyyyMMdd');
        rec_ac21.aae206 := null;
        rec_ac21.aae011 := 'app';
        rec_ac21.aae036 := sysdate;
        select sb_prseno.nextval into rec_ac21.prseno from dual;
        select sq_aaz159.nextval into rec_ac21.aaz159 from dual;
        rec_ac21.aac050 := '01';
        rec_ac21.eaz132 := '1';
        rec_ac21.aac008 := '1';
        insert into ac21 values rec_ac21;
    ......
       commit;
    Json.Newjsonobj(j_JsonmainOut, TRUE);
    j_JsonmainOut := Json.Addattr(j_JsonmainOut, 'recode', Ret_ErrCode); --交易結果
    j_JsonmainOut := Json.Addattr(j_JsonmainOut, 'remessage', Ret_Errmsg); --交易結果資訊

    Json.Closejsonobj(j_JsonmainOut);

    --json轉化成資料
    as_outmsg := Json.Json2string(j_JsonmainOut);
    Return;
  Exception
    When Others Then
      Ret_ErrCode := 'ERROR';
      Ret_Errmsg  := '交易異常出錯:' || sqlerrm;
      sbp_err(Ret_ErrCode, Ret_Errmsg, as_outmsg);
      Return;
 End;

介面開發中主要的是對一些判斷邏輯進行編寫,當一切判斷規則都符合後才進行表增刪改查操作.

儲存過程介面測試

寫完介面肯定是先要自己這邊測試下的啊,功能判斷是否正確,這時候就瞎**輸入可能的錯誤正確情況了… 儲存過程的除錯就一個一個試咯.
除錯入口截圖
這裡吐槽下續保的判斷真是多啊,多到我都佩服制定這規則的人怎麼想到這麼細緻的呢,什麼腦子腦子腦…

介面開發文件完善細緻編寫並提交產品與APP開發人員

介面開發好了就要修改完善之前寫的介面文件了,那個先前版本的文件是讓APP端先進行大體開發寫的(同步開發!),具體的引數現在要調整之類的.這期間也是有煩人事的,不過都是比對前後變化的問題. 然後就是發給產品和APP開發了,我這邊稍稍喘口氣,等APP端完成模型和功能再聯調吧!

APP端完成模組功能後聯合測試調整

上傳個判斷截圖

聯調是個盡出么蛾子的過程,什麼奇葩不可能不理解的錯誤都跳出來嘚瑟了.APP前端改,APP服務端改,我這邊後臺改,改,改…產品的訊息不停啊.也是這個時候才能大規模發現問題不足.不過測試的妹子qq倒是加了不少=-=

完成各項測試後上線正式版本

測試問題收錄

等各項測試完成且確認沒有問題後,將測試庫的介面程式移植到正式庫,APP端也將程式部署到正式版本供使用者使用,一個完整的APP開發即結束了.

最後感覺一個APP的開發流程跟我之前想象中還是有很多區別的.比如大部分幾乎所有的判斷邏輯都是我在接口裡寫的,還以想java一樣呢,不過確實寫在儲存過程裡感覺更快一點呢…不知道對資料庫效能有什麼影響(待研究!)

待提升的地方還有很多:

判斷邏輯有待優化

查詢語句有待優化

http請求連線方面有待加深

plsql語法有待學習

與客戶,專案成員交流有待提升(畢竟溝通的好會讓開發事半功倍!切身體會啊)