记录一下当年火爆全国的P2P平台是怎么来的

今天是2024年，已经到了年底了，今天是平安夜。打开自己的多年前的笔记本，整理一下很久之前的资料，回忆记录一下当年的工作内容吧。

背景：

2018年，其实P2P已经接近尾声了，但是公司之前就有这样的一个平台，只是系统没有接入存管系统。迫于上面给到的压力，必须把安全问题解决了，于是集团就在上海组建了团队，来搞定这个事情。

目标

首先，目标非常明确，解决现在系统的瓶颈，接入银监会要求的存管系统，这才是一个符合要求的平台。

行动

团队组建
当时接手的项目是用php写，所以为了完成原有系统的bug修复，指定是少不了php开发。
然后就是系统重构升级，用java重构少不了java开发。
应用包括安卓、iOS、微信公众号、PC端，所以前端都有一个对应的开发人员。
测试和运维各一人。这就是团队配置。
业务培训
其实大家对这个行业都不懂，后来逐渐熟悉了，发现也没有那么的复杂。并不是股票或者基金那种巨复杂的业务。
期初大家都不懂的时候，就从代码梳理逻辑，对照着数据库梳理逻辑。把任务拆解，然后每个负责一个模块进行分析，要求他们画出对应的流程图，然后每天下班之前开始分享。这样一点点的把流程搞清楚。
修复问题
整体流程搞清楚以后，就先把原来的系统跑起来，然后测试走主流程。当时让运维给我们搭建了一个禅道工具，我这边就用这个来跟踪问题和进度。
除了这些，要求每人每天都要进行今日总结。总结今天都干了什么，明天要做什么。这也算是一种跟踪的方式吧。因为时间长了，每个人都记不清楚5天前都干了什么了。
功能模块拆解
原来就是一个单体应用，代码一坨，很难排查问题，也很难找。为了重构，必须在核心流程的基础上，把功能模块进行拆解，细分，然后设计扩展后面可能会发生的业务变化。于是就有了这样的大体模块：
数据库拆分
原来的数据库表中最多的一个表中有180+的字段，一个表有很多看起来重复的字段，但是你又不能删，只能通过代码搜，看看这个字段到底是是干什么的。后来发现，这些代码应该是很多批开发人员写的代码，不断往上加东西，加的时候也不会看之前是不是已经存在了这样的字段。
就这样多字段的表，不拆是会写死人的。
先是纵向拆分，多字段拆少字段，根据数据变更频率、业务所属进行拆。
然后就是核心的数据量大的表，并且在未来可能会持续增加的表，我们尽量拆的更细一点。这样就算分库分表也会轻松一点。
拆的时候一个重要的原则是，经常变动的表独立开来，这样不经常变动的表用缓存减压。
当时用建模工具是powerdesigner,结果就这样了。
除了数据库拆分，我还得对系统进行设计，设计具体到每个业务模块使用的错误码CODE范围，每天大家走了，我还在加班工作。因为这些大的框架不出来，大家没法进入开发阶段。

为了抢时间，先搞核心功能。
艰难的开发
每个客户端需要的数据都不一样，展示的样式都也会不同，为了让开发更顺畅，我要和业务和产品沟通好这些问题。有时候细节到一个光标的颜色的统一。
之所以称为艰难，首先是因为需求不够细、模棱两可的不确定的东西开发是没法干的。所以，沟通是特难的事情，因为这个产品是个新人，不懂p2p业务。我们还会有业务考试，她考的最少。三次不过的直接走人。其次是开发过程中需要很多其他的组建支撑。比如：短信、邮件、三方登录、后面测试安全性都需要我去搞，搞好了给他们提供一个账密。
外部沟通
除了内部团队沟通，还要和外部对接的团队沟通协调，比如接入存管系统：
解决各种奇葩问题
程序员能遇见的问题都是各种奇葩问题，你还得给给出解决方案。有时候问题的解决方案都不在这一层面上，你得跳出这个层级去思考。
比如：点击返回按钮，返回到上一页的功能。有时候理论是很美好，但实际上想跳转到指定的页面的时候就不能实现了。因为传统的思维模式一直都是history.go（几步）。这种局限性很大。为了实现这个功能，我就让大家统一，需要跳转的时候自己记录要跳转的地址和参数，不要用js自带的history.go（几步）。这种才能彻底解决问题。
一边为了进度加班，一边为大家争取福利
加班调休、加班饭补、加班打车报销等等。
一个刚组建的团队，这些最开始都是没有的。你得找领导申请，找老板去说。
老板只认投入产出比和什么时候上线。