关于平湖人社APP后台开发总结这是我**次做联合开发
发表时间:2023-11-01 18:02:27
文章来源:炫佑科技
浏览次数:110
菏泽炫佑科技
关于平湖人社APP后台开发总结这是我**次做联合开发
这是我**次做联合开发。 对于一个多部门、多人合作开发的项目,我这个刚毕业的新手,还是有很多挑战和困难。 但是,我只能通过实际的项目开发来学习东西。 我话不多。 话不多说,咱们直接进入主题吧。 (忽略我使用的英文标点符号,开发不容易……)
我总结了APP后端接口开发的以下几个部分: 需求分析与组织
需求分析主要是指我在现场与客户协商,讨论分析需要完成的大致功能和APP原型,然后整理出早期的需求并发送给产品经理。 产品过来后,我会和客户讨论具体功能等事宜。 主要了解一般功能和APP原型。 要做的事情和业务系统的区别是为了我以后可以参考业务系统来判断书写规则。 这段时间我会准备相关的界面编写事宜。 我其实不太懂一般的界面写法。 我以前从未这样做过。 我从来没有接触过,所以就一点一点地询问了项目经理。 幸运的是,项目经理告诉我,之前其他项目组已经做了一个界面开发的模板,可以借鉴。 这就是我开始为界面开发做准备的过程。
分析业务需求涉及的模块功能及数据库关联表
产品经理把需求文档和APP原型整理好并发给我后,就开始分析他要完成的任务。
这里我就以APP中*重要的功能模块——人员保险续保为例。
该功能主要用于人员更新操作app开发,涉及数据表结构较多,判断规则较多,完成难度较大。 当然,这也是我花时间*多的功能。 我主要是通过业务系统代码看很多续费规则是不够的。 幸运的是,客户理解了续订的麻烦,并向我详细解释,并在后续的开发和测试中不遗余力地提供帮助。 我非常感谢他们。 完成续费需求分析后,我就不急着写界面了。 ,主要是我现在写不好,得先对接口函数进行UML建模(其实之前接口写的时候吃过亏,缺乏详细的分析判断规则导致代码被非常臃肿并且不容易阅读和理解...)所以建模非常困难重要!!! 有助于理解复杂的关系判断。
部分判断流程图:
接口开发文档大致编写完成,提交给产品和APP开发者
接口开发文档以前没写过,所以写起来比较困难。 也是询问项目经理才完成的……
1.主要地址: 2.接口函数统一为 3.传入参数:所有传入参数都是类型,格式为json字符串,基本格式为(传出的类似,不再列出):字段名是否可以type是一个空字段吗? 阐明
杰杰杰
不
交换节点
某人
不
社会保障代码
不
身份证号
吉利克斯
不
交易类型
json格式内容:{"jhjd":"","sbbh":""," ":"","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的开发就结束了。
*后,我感觉一个APP的开发流程和我之前想象的还是有很大的不同。 比如大部分几乎所有的判断逻辑都是我写在界面中的,和Java类似,但确实感觉像是写在存储过程中。 快一点...不知道对数据库性能会有什么影响(有待研究!)
还有很多需要改进的地方:判断逻辑需要优化、查询语句需要优化、http请求连接需要加深、plsql语法需要学习、与客户和项目的沟通成员有待提高(毕竟良好的沟通会让开发事半功倍!亲身体验)