发表于： 2017-06-07 23:57:40
1 1217
一、今天完成的事情：
今天都在听方案评审，就记录一下自己听到收获的东西：
1 修真院16期后端方案评审：
针对新增的接口说几个收获的点：
1.1、对于内容管理这一块，方案设计中文章列表（还是banner...我忘记了）使用的是按照publish_at进行DESC的，可是这个不能按照这个进行排序，改正方法为新建一个level int ，按照level进行排序。
SQL语句需要两种查询方式都写上，为LIST。
1.2、在约定中，针对产检问题列表进行讨论，有几种方案。当时思考其实真的没想法（有一小部分是没带耳机...没听清内容），后来老大给出了第二种办法的时候，发现其实就是自己想表述接近的。。。就很尴尬，自己没学到位。
方法一、：对一个title对应一个content进行管理和存储。
方法二、：把所有title放入一个里面，content去时间倒序的第一条。（其实想了一下实现，没想清楚）。
分别有什么好处和坏处：
方法一、这样单一的关系能快速寻找那个title有问题，缺点，这样存储如果有多个内容展示的时候默认不知道展示那一个。
方法二、默认为展示最新内容，缺点，当数据量大时可能出现难以管理的情况。（不知道这两种解释对不对。。。。）
1.3、拖拽排序这一点其实没想明白。这里就记录一下关键字。
2. 萝卜多复盘后端方案评审：（加入听讲的时候感觉讲的差不多了，就记录自己几个印象深的东西）
2.1、后端公司职位删除 删除一条简单sql语句是不行的，因为company通过id关联了很多表，信息可能冗余，这里提到了禁用级联（其实不太懂），不能使用物理删除
这里其实不太懂禁用级联和物理删除区别？...那这个是删除的操作是什么呢。
2.2、公司标签的问题，
方案中给出的是当定义一个接口跳转的时候实际是实现了两个接口的方法，输入标签完成就保存，提交的时候刷新，可是这个做法不对。思路有为无论用户怎么进行操作，直接先全部删除，最后提交的时候在一次提交保存。这个做法感觉交互量也不大0-0但是就是感觉麻烦，我也想过，但是当时就没直接想到这一点。好像这是最优解决办法了。
2.3、公司的认证、冻结两种状态的提高效率解决办法；
定义两个操作类型，type、status.type定义为认证或者是冻结的类型，status，定义是认证/未认证、解冻/为解冻的状态。就不用重复分为两个接口写了.二、遇到的问题：就是上述任务中提到的问题，外加16期中状态侧栏为要把线上/下报名也一起管理呢，这里也有点疑惑。
三、明天计划的事情：
四、收获：感觉两个评审真的赚了啊，切切实实的跟着项目思路走，考虑哪些不足..虽然基本都在跟着讲师走了。没有跳出思维思考....（PS：复盘项目评审记录中，若有听错的地方请指正，可能是自己表述错误，或者是理解有问题，还请多多指教。另外标签的解决办法- -还有哪位师兄能讲解或优化一下（虽然大佬们的确想的很厉害了））
返回列表
评论