养卡代还系统

xym520

这个套系统算是非常完整的，由我自己全程设计构建的系‌‌统。其他几套系统多多少少是与同事合作之类的，并没有那么完整的经验。

不算大的一套东西，但是却的确学到很多，主要是关于数据库设计、设计api、代码结构设计、项目推进、项目时间和难度的预估、测试预估。

项目从拿到需求到积分系统的完成(包括对接现有支付模块，编写测试之类)其实耗时不多，大概在16个天，对账系统包括测试做了4天总工作日大概在20天。但是这个看似正常的时间，跟最开始估计的时间相差甚远。我在前期有很多加班包括周末加班的情况下才勉强能照着现在这个进度完成，实际上最初估没有对账系统的完成时间只有12天，中间差了4个工作日，算上加班的时间可能差了7个工作日。可能这就是不经常预估项目时间的人容易犯下的错误吧，对自己的编码效率莫名自信，殊不知里面其实有大量不可控因素影响进度。其中很大影响比重在于修改前面人写的支付模块的代码上，不仅需要大量时间阅读前面的人写的代码和思路，还需要把自己的逻辑加进去，这极花时间。所以估时间的时候一定要预留充足的时间，这个后面再提一下。

(一) 还是按顺序来吧，先说数据库设计，设计API，设计代码结构花了大概两天时间设计了数据库，一共涉及到11张表。弄好了之后拉着leader和主管开了一个短会，我阐述了我的设计思路，然后拉着他们帮我看看设计是否存在问题，或者有没有地方有漏洞是我没有办法考虑到的。这里我其实设计了两张流水表，每当有一笔收入或者支出的积分，都会在支出和收入的流水表里面增加一条记录，但是最开始的时候，因为某些原因我可能需要update流水表里面的字段，但是leader告诉我流水表最好不要有update的操作，这样可能比较容易出错，流水表只往内记录，不更新，这样不会出问题。这点使得我开始从表稳定性去思考这个问题，觉得还是有一定道理。因为流水表最终在结算的时候可能用于对账，一旦这个表因为更新字段出现问题，那么对账就会出错，电商系统的对账出错的话。。。。。

找前辈帮忙看因为他们比我更熟悉系统，所以一定要拉他们帮自己看看，否则有些坑，或者以前弄的hack可能会影响到新的系统进行某些操作。做了一些改动，然后我们一致同意了一个决定，就是如果全部做好一起上线代码量超大最少2k行，可能完全没有办法review。

毕竟要花时间去看一个2k行代码的项目，还是需要花费不少的时间。所以决定将项目拆成两块分批上线。由于构件积分的查询存储使用之类的东西是完全不会影响到现有系统的，所以可以单独上线，然后将接入现在的支付退款系统作为另外一部分进行上线。这样就拆开了现在逻辑和新构件系统的耦合，看代码上面也会变得稍微方便一些。

当时讨论完之后,leader让我最好当天的下午，或者第二天的早上将这套东西要提供给app的api定出来，大概需要哪些api。api定下来之后，写东西就可以按照api来依次实现功能了。

这个步骤真的是让我大受启发，在数据库设计完成之后，就设计到底要提供哪些功能出来，就能完成初步的api设计。这样想就可以安好想提供的功能依次编写代码了，也不容易漏掉什么东西。其实这里面最难的部分，就是将思路理清楚，能让自己知道究竟有哪些工作完成，什么先完成，什么可以后完成比较好。在设计完api和数据库之后我可能需要画一些图，和做一些笔记来辅助我思考这些问题才可以让我自己的思路变得更清晰。我自己的画拿了几张a4纸在上面大概画了写了一下有哪些api，名字大概叫什么，提供什么样的功能，可能会设计到的表之类。