电商积分支付系统构建经验与总结

这个套系统算是很是完整的，由我本身全程设计构建的系统。其余几套系统多多少少是与同事合做之类的，并无那么完整的经验。

不算大的一套东西，可是却的确学到不少，主要是关于数据库设计、设计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，名字大概叫什么，提供什么样的功能，可能会设计到的表之类。

 

最后这个chapter里面关于代码结构：

 

dao里面存放了各新建表的模型，因为使用orm因此使用到这些模型。

model里面存放了各类中间逻辑，包括调用dao里面的方法建立更新删除数据，拼接各种数据。

外面api提供了各功能的api函数，api层我只处理了入参，保证各入参的类型合法而后传给model对应的函数进行进一步的逻辑处理。

const里面存放了各类可能会使用到的常量。在设计常量存放的时候此次踩了一个坑，最好把有哪几个可能出现的常量类型分别创建一个类，在类下面写，并且最好提早分配好他们所属的数字区域。打个比方，咱们可能有支出和收入不一样的常量需求，千万不要写成这种：

class IncomeConst(object):
    INCOME_NORMAL_REVIEW = 1  # 正常评价得到积分
    INCOME_REVIEW_BONUS = 2  # 好评得到的额外积分
    INCOME_UNLOCK_ORDER = 5  # 订单积分解除锁定
    INCOME_REFUND_ORDER = 7  # 退款退积分


class ExpenditureConst(object):
    EXPENDITURE_FRESH_MEMBER = 3  # 爱尝鲜购买
    EXPENDITURE_LOCK_ORDER = 4  # 订单积分消费锁定
    EXPENDITURE_OFFSET_CASH = 6  # 积分抵现

 

应该首先肯定income里面占用的是1000-1999的数字 那么expenditure就能够占用2000-2999的数字 这样能保证一样类型的const是连贯的就像这样：

class IncomeConst(object):
    INCOME_NORMAL_REVIEW = 1000  # 正常评价得到积分
    INCOME_REVIEW_BONUS = 1001  # 好评得到的额外积分
    INCOME_UNLOCK_ORDER = 1002  # 订单积分解除锁定
    INCOME_REFUND_ORDER = 1003  # 退款退积分


class ExpenditureConst(object):
    EXPENDITURE_FRESH_MEMBER = 2001  # 爱尝鲜购买
    EXPENDITURE_LOCK_ORDER = 2002  # 订单积分消费锁定
    EXPENDITURE_OFFSET_CASH = 2003  # 积分抵现

不要把本身搞得像个精神分裂同样，遇到了就往里加一项数字上涨一个。。。。简直不忍直视＝ ＝。

exception里面存放了各类可能会抛出的错误，统一继承自Excepition类

 

(二) 项目推动

项目推动的过程当中，无非是按照前面设计好的东西循序渐进的一个模块一个模块的写。其实中间也没有碰到什么特别坑爹的事情，只是把原先的两个上线步骤拆成了三个，由于发现前面其实虽然没有构建整套积分支付的东西，可是却有记录用户积分的东西，在用户评论商品以后会给用户记录积分的，这就形成了前面多多少少写了一些积分的东西，我须要把这些原有的东西分好类从新放回到积分新设计的积分模块里面去。这一步其实我在估时间的时候没有想到的，因为前面写的代码比较随便，致使我迁移起来很费劲，有很是多的依赖满天飞，多花了不少时间，并且是影响线上的东西不得不当心翼翼，测了又测。总结了一个经验，先从依赖最少的地方开始拆，拆完一块就测一块。这样一步一步的弄几乎不会出错。千万不要一连迁好几块的东西，最后再来一块儿测，那个时候要是再测出了问题，我相信改起来的难度很是大。你要依次去排查是前面哪一个改动致使了这个问题，这几乎的是不可行的。

迁移的理想状态是，全部东西都有单元测试，若是没对的状况下，跑单元测试都会报错，你就能及时发现并切改动。现实是(好残酷的样子)，若是没有单元测试，你可能须要稳健的一步一步来。当你把简单的东西都迁走以后，你会发现以前那些难以迁移的东西也变成容易迁的东西了。

 

(三) 项目进度预估，对项目时间包括测试部分的预估

就像第一部分谈到的，其实若是时间很是充足和从容，你可能有大把时间来按照我上面说的流程对关键部分进行仔细测试，甚至给每一个地方都带上单元测试。现实是若是你本身估的项目时间太短，你可能没有时间来完善测试方面的事情。前提是你的公司里面没有专职QA,测试几乎须要你本身完成，这个时候，将测试时间估算进你项目进度显得很是重要。我此次的测试时间大概占完成项目时间的30％，这个结果很大部分取决于我还用了很多业余时间完成项目或进行测试，以及依赖一些之前同事编写的支付部分的测试，若是所有本身来的话我估计时间至少须要估完成项目时间的50％时间用于测试或者编写单元测试。也就是说若是你估计这个项目你15天能够写完，你可能大概须要额外的7天时间用于测试和修复测试出来的bug，以及本身对代码二次review。这样的进度才能保证你代码的质量，以及在上线以后不用提心吊胆是否会被客户端或者web端的同事找麻烦。

对时间方面的估算，没有几个项目的经历是确定估不许的，在你发如今deadline以前完成不了项目的时候，必定要向本身的leader说明项目延期，以及由于什么缘由致使了项目延期，而且尽快完成项目。因此对项目推动节奏的把控，可能严重影响项目质量，既不能够彻底没有压力和时间上的deadline随意完成项目，也不可把项目时间卡得过于紧，由于中间除了我上面分析得问题，还又可能出现诸如你须要请假有事，中途任务的插入。

 

以上。