2017个人总结
‘轻飘飘的旧时光就这么溜走,转头回去看看时已匆匆一年’,就像歌词中描述的这样，2017已经过去，‘或许明日太阳西下倦鸟已归时,你将已经踏上2018再战的征途‘，每到这个时候，想想过去的日子，总有那么一丝谈谈的忧伤和忧愁，因为我们每个人都大了一岁，再想想自己过去工作的一年，你是否完成了目标，下面以月份为时间线，总结下我过去的一年在首展所做的事情：
3，4月份 杉德银联后台，从3.23号入职公司，一个新的项目后台，就是杉德银联后台这个项目，因为以前的经验都是电商领域的现在是做移动支付行业，所以最开始还是对业务需求专业词汇，例如支付公司各级的费率所困惑，银联项目分为openapi接口和后台系统，由于openapi接口时间紧，加上刚来，前面几期的需求会也没有参加，表结构也不熟悉，不了解不熟悉到底后台功能，但对于我个人来说是个好的机会，了解公司的产品业务，虽然后台表面看起来就是些数据管理查询统计的功能，但是这些数据到底是怎么进来的，所以就需要一步一步去了解，商户入驻 收单交易，打款这些整个需求流程，自己参与了后台技术设计，整个后台由东源，海峰，凯洪，我4个人一起开发，因为是前后端分离的，还需要与前端联调，所以前端接口文档要写好，
通过这个项目总结几个问题，
1 ，开发工程中每个人的进度问题，作为一个负责人，要非常清楚的了解，尽早暴露开发中的问题早解决，每个人的技术功底不一样，有的人开发效率快，有的人慢点，我们是一个团队，开发工程中的问题应该互相帮助，最快时间解决问题
2，前后端规范问题，例如接口到底是get post请求，数据请求格式，字段名更改后，要及时更新文档，文档上要写好，不然联调浪费时间，更改接口后，要及时主动通知联调人员，不能被动等对方来问。
5月份：主要做了京东支付接口和清算平台自动对账需求，器中自动对账分为支付宝和微信对账，找出差异订单，当时支付宝订单一天15万左右，微信30万左右，利用的是redis中的sdiff命令来实现的，这个需要看起来简单，做起来不简单，由于测试环境没有足够的数据，支付宝沙箱环境没有对账单数据，支付宝的对账单只能到预发环境测试，当时遇到的困难支付宝对账单中的乱码，我记得当时解决了很久，要不停的修改代码，修改日志，然后发布测试，然后就是微信对账单微信没有准确的生成时间，文档上只是告知上午10点前，但也有可能10点没有生成好，需要每隔一段时间尝试着去调用微信对账单接口
自动对账需求上线延迟了几天，反映出来几个问题，
1，时间没估好，尤其是里面的自测时间，风险点 难点没有考虑好
2，自动对账 对于后面部分退款需求上线后，涉及到修改，代码质量扩展性要考虑好
3，当时的每天峰值量级在50万，一年后数据翻倍了，所以性能 存储这块也要考虑好，例如放在redis中数据的过期时间不能太长
4，每天对账单需要遍历财务表，当时第一版虽然是凌晨跑job,但是每次查询的时间太慢，后面优化了sql提高查询速度
6月份：开始接手快付小店的需求，快付小店系统比较多，涉及到 h5接口, app接口，后台好几个，支付公司T0, T1后台，代理商后台，运营后台， 小店里的业务很多，留下的坑很多，当时要理清小店相关的表，业务，核心逻辑，从tower历史需求里面下手，从当时的分销需求入手，后来分销因时间太久停掉了，当时微信商户池扫码需求上线后，每天的交易量上来了，并发量上来了，系统中有很多慢sql,优化了耗性能的业务，耗性能的sql, 各种余额计算的逻辑
总结：
1，小店涉及到的系统多，代码肯定有重复的逻辑，代码拷贝来拷贝去容易遗漏
2，随着交易量并发量的上升，每一笔的资金，余额不能错，不能重复打款
3，修改费率要特别小心，每一个sql的修改要经过审核，大表的修改要在业务低峰时间执行
7-8月份：清算平台平台化，由于清算平台指只对接了平安银行一家，平台化系统需要对接多家银行，当时也是将原来的清算平台系统拷贝一份出来，数据库表都是单独出来，原来清算平台是drds，平台化换成rds, 订单表讲原来的多个订单表修改成了一个，然后就是商户订单财务相关表加上银行的维度，虽然看上去简单，因为原来清算平台的逻辑是针对平安银行的定制版本， 平台化的代码需要去除定制特殊的部分，也就是说需要熟悉清算平台的业务，清算平台里面获取费率的逻辑好多是可以优化的，有些表中没用的字段去掉，相当于是一份简单公共的版本，去掉无用的代码，平台化上线对接了光大银行，招商银行因对接模式不一样，是一种授权模式，当时也做了个授权的功能区获取appid, 平台化后面的需求加入了网关费率，商户改造需求等
总结：
1，平台化系统 对接多家银行， 安全，稳定，可扩展性考虑要全
2，平台化系统，最开始可能量不大，等一定时间后，多个银行对接进来，数据量就上去了，数据存储问题，还有就是不同银行的个性化处理，因为不同银行打款肯定不一样。
3，代码质量需提高，代码最开始全部来自原清算平台的，正好在新的平台上重构部分非常冗余的代码，要写出容易维护的代码，代码健壮性
9月份：现金贷零用钱项目，这个项目我承担项目经理的角色，技术经理是海峰，公司都非常重视的项目，责任重大，机会并存，该项目主要功能点风控爬虫，个人信息认证，审核，放贷，催收，其中数据爬虫这块是个难啃的骨头，因为如果自己来做爬虫里面有很多的坑，爬虫页面经常修改，就爬取不到数据了，所以自己做的爬虫系统不稳定，会遇到各种各样的问题，这样就对个人信息认证这块有影响了，然后就是芝麻认证，身份证实名 银行四要素鉴权，生活圈数据接口，还款打款接口 这些外部调用的接口较多，如果某一个接口有问题就有可能影响整个项目延期，所以需要提前预估好，还有在项目正常进展中，可能有很多不确定因素，例如中途插入其他任务
该项目因为后面的快付小店底层切换网商银行需求更重要，十一之后暂停了。
总结：
1，第一次承担该角色在团队协作沟通能力需要提供加强，把控整个项目的进度和各团队遇到的问题，推动协调项目的进展
2，要发挥个团队人员的积极性，自己不能只是一个编码的角色，要让项目中的人员充分发挥他们的能量
3，项目开发中的进度，问题，要及时通知，及时反馈给团队中每一个人，并给出解决方案
10-11月份：快付小店底层通道切换网商银行
这个需求比较大，相当于要将快付小店底层支付通道全部切换为新的网商银行，T1的保持不变，系统修改的点比较多， h5,app,相关后台代码都要修改，并且要考虑老商户的情况，以及要考虑到正在使用的代理商，商户余额提现问题等等，前期技术评审没做好，技术文档太简单，详细的计划也没做好，很多东西没有考虑到，开发联调过程比较曲折，结果匆匆发布到测试，最开始流程走不通，到处是系统异常，开发人员缺少自测，联调并不顺利，该需求最后因政策原因没有上线，从这个需求可以总结到：第一，以后遇到类似的大的需要，需要评好详细的开发计划和遇到的风险，第二，项目开发质量必须保证，必须做好自测，第三，除了自己开发上的问题，能提前督促业务方，给运营人员提供统计数据，让他们早点知道上线后的各种问题，不然我们技术人员太被动，辛苦做完了，没有啥结果。
12份：服务化项目
有幸参与生活圈服务化项目，这是一个从零开始的全新的项目，服务化都是现在互联网公司由小变大技术迭代的必经之路，该项目也是技术部门的一把重要利剑，因为服务化需要将原来老系统拆分独立出一个个服务，九层之台，起于累土，需要我们做好最底层的一个个服务，站在阿里edas这个巨人的肩上，我们也是处于摸索阶段，开发模式跟以前不一样，目前调试比较麻烦，一台机器需要启动多个服务，一个服务启动耗时较长，所以效率并不高，当然我们也在咨询阿里中间件的人员，急需寻找一种高效的开发， 一种服务化的最佳实践。我们正走在服务化的路上，前面有曲折，有坡道，有坑洼，我相信任何艰难险阻都可以战胜。
一年下来，从上面每个月所做的事情总结到，每个需求每个项目时间都得很紧，这也是创业公司的特点，要以最快的速度抢占市场，快速迭代，快速优化，所以我们每个开发人员的压力都很大，所以我们需要将压力转化为动力，贡献自己的一份力。莫为浮云遮望眼，只缘支付全是钱，每个项目都要考虑到资金安全，要有责任心和敬畏心。一个个项目下来，总结过去，目的是让我们看到曾经的不足，哪些点还可以做得更好，这就是一种成长。
2017，不知不觉就过去了，回首参与的项目，有的没有做好，非常愧疚还需更加努力，期望2018能改善几点，不踩重复的坑，代码质量性能优化这块重点关注，能站在更高的角度思考问题，要让小组的人员成长起来，改变自己的弱点，向海哥学习，分担更多的责任。
要加班，要复盘，只因我们在一船；零事故，零宕机，新年铁军更努力；2018，愿在新的一年里，做得更好，发挥出自己最大的能量，和公司一同成长，剑锋所指，所向披靡。
心若在，梦就在，天地之间还有真爱，看成败，人生豪迈，2018，我们卷土重来。加油。
总结完了，一首中英混诗，祝福大家在2018更上一层楼。
《2017总结》
锄禾日当午，
What doesn’t kill you,
春风吹又生，
make you stronger！
