一张表遇到的问题

最近做的一个模块，就是一张表的增删查，但是遇到的问题却不少，总结一下，为以后提个醒。
该项目是前后端分离，后端在开发时看不到页面，仅用postman调试；首先，

遇到的问题有以下几点：

1. 字段和前端没对应上；原因是沟通的少，导致后端加的字段前端不知道，最后没保存上（设计人员中途加字段）
2. 数据库字段类型被改，char(3)被改成了varchar(3)；用的Oracle数据库，这个字段在做查询的时候就发现（太笨了，花了很长时间才发现），原因是char是定长字符串，char(3)即使只存01两位，也会用空格把剩余一位补上，而我的处理办法是后端给他加空格，没想过改数据库，后来被别的用这个字段的人改了字段类型，直接导致我这边查不出来，排错的时候也一直在前后端找，最后才想到数据库！所以说团队里一定要固定一个人更改数据库，并且做好变更登记
3. 需求不明确让改唯一性校验规则；这就很无奈了，还好改动不大
4. 加了规则校验后，缺字段；这就是前期设计工作没做好带来的返工，设计字段的时候就应该考虑好这张表的用途，每个字段的作用，哪些是展示和规则必须有的字段
5. 事务问题；保存完数据需要先落表然后规则部分去查表，需要先让保存提交事务，这个问题经常遇到
6. 异常未抛出，前端没有弹出提示；这应该养成习惯，后台抛异常，且提示内容要明确，具体
7. 删除操作，由于后续业务可能是基于本表中的数据进行操作的，所以在删除本表数据的时候，还要删除基于此条关联数据进行的后续操作，所以在做自己模块的时候还要考虑到与其他模块的联系，不要只考虑自己的模块，了解需求要从整体看
8. 生产问题，ETL跑数据说有个字段不能为空，让补全；但这个字段不是我存的，我需要去找对应的人去对接（还好之前留意过这块代码知道咋回事），然后前后端开始排查问题，都说没问题；问题又留给我了，我又重新确认了一遍这个字段涉及到的需求，想确认一下生产上这个表的其他字段是不是都有值什么的还是只有这个一条数据，最后发现这个字段有为空的场景，不应该有非空限制，还涉及到另一个字段，要空都空，查了生产数据后才发现确实没走给该字段赋值的操作，没值是正常的，最后找到ETL，看了他的存储过程，找到了问题根源-字段对应错了。
   小结：这个问题其实从一开始就应该先从分析这个字段的场景入手，什么情况会为空，应不应该非空限制，从而想到不走某个操作就是为空的，进而推翻这个问题，就能省下排查前后端问题的无用功，为生产问题节约时间；也给我一个警告，不要只管自己的需求，学会分析问题，敢质疑问题，不要只局限于找自己的问题。

总结：

做了这几个项目下来，大部分是对单表的增删查改，但每张表都不是孤立的，表之间都存在一定的联系，所以，要尽可能考虑 的全面一点；

1. 首先，了解需求，不应该只限于完成本功能，还要考虑整体，会影响到哪一步，这步的目的是什么；其次是参与设计，因为没有人是万无一失的，总会有纰漏，先自己分析，再对照设计文档，这样可以减少后期的返工，提高开发效率
2. 开发时，应该前后台都要关注，不应只关注一边，这样后期排错也快
3. 排查问题的时候要敢想，即使觉得不可能存在的情况，也要再次确认，很有可能就是那个问题
4. 保存，该有的字段一定要和规则协调好，保存是为了后续步骤的查改删，不是简单地保存