项目禁忌1000条

最近发现自己犯的错误有点严重，实在挂不住脸，希望这里不要记太多。

1. 你以为

（1）之前有做一个需求，就是要保持三个模块的某个日期一致，我当时简单找BA问了下，就去做了。做的时候发现，三个模块有两个模块的日期始终保持一致，所以下意识以为只需要改另外一个模块的日期就好了。当然，测试也没测出什么问题，上线了几个月，用户说你这个模块的日期不对呀，多了一天，然后大家一看，确实，其实应该改另外两个模块的日期。然后我就背锅了，更重要的是，这个模块的日期被很多模块和功能依赖，其中还有一些计算功能，除了改这里以外，还好batch update已存在的数据。天呀，这简直是一场灾难！所以，你以为，请不要你以为了。一定一定要步步小心，步步想，搞的明明白白，搞清楚其中的关系，否则后果承担不了，gg。

（2）最近用同事发现一个很严重的bug，发现产生的数据会double甚至更多倍，然后另外同事去看代码，发现我当初写的代码有严重问题，影响了五个模块，脸瞬间就挂不住了，幸好用户还没用这块的功能，不然铁定gg。总结下来，是自己当初没注意业务中的层级关系，导致用了第二层数据调取了第一层数据，然后再通过第一层数据调取了第二层数据，就导致第二层如果数据有N条的话，产生的数据就是N*N，真的要被自己吓死。需求没搞清楚，关系没搞清楚，真的不要直接下手写代码呀，会死的。

（3）merge code，自以为可以holder的住，处理了其他人写的代码，然后之后gg，在生产环境发现了比较明显的界面问题，紧急改了重新上，老脸挂不住呀。merge code，有冲突一定要一起看，即使没有，也要再看一两遍，另外merge后的代码在code review时也要过下，这样才能确保merge没有问题，尤其是从另外一个分支merge代码时。

2. 请谨慎对待DB某些数据的删除操作

（1）之前有做一个需求，要增加4个字段来替代原来的一个字段，因为那一个字段的信息太多而且设计不合理，需要把其中的信息拆成4份。然后我首先就删掉了这个不合理的字段，然后创建了4个新的字段，之后就傻眼了，之前的数据找不到了，是需要把原来数据恢复到新字段里的。幸好这只是测试场，幸好这些数据也不是没办法恢复，只是这样会需要很长时间。我尝试恢复并且成功，用了一整天的时间，真的费时费力不讨好。差点就犯了大错！所以，请谨慎对待DB某些数据的删除操作，宁可不删，等过一点冷静下来再谨慎处理。

（2）之前有做一个需求，要更改某个字段的类型，我就直接drop掉这个字段，然后创建一个同名的新字段，后面被同事看到了，结果可想而知，真的无地自容，这种处理方法的结果就是比灾难还严重，原来的数据就真的没啦，哇哇哇，宝宝想哭！

3. 请谨慎对待DB某些数据的更新操作

（1）上周五临下班前，接到一个support，要更新DB中的三条record，然后自己根据用户给的信息编写了update sql，然后执行，以为就完事了。结果第二天效果，发现没效果，然后看了下sql，突然有一种直觉，写错了，然后仔细一查，发现我少写了where条件，导致更新了上千条数据，完蛋了。周末两天使劲恢复数据，那个心累，那个心惊胆战。所以，切记要先select再update！！！

4. 对数据migration请再重视、认真、谨慎些

参与的一个项目之前做了数据的migration，而且是第二次做这件事情，但是做完以后一团糟，我同事的电话被客户打爆了，持续大约一周吧。针对用户和后面我们自己发现的问题，分为容易发现型和较难发现型，在查问题过程中发现有几点做的很不到位：

（1） 首先针对较容易发现型。由于我们是周末做的migration，做完以后就没测试各个模块了，周一用户就开始用了。一个是我们的自动化测试脚本那段时间有些问题，跑不起来。另外一个是我们没有做足够的人工QA Test，因为我们这个是比较重大的事情，所以周末加班来验证功能是完全有必要的，尤其是缺乏自动化测试的情况下。哪怕只是走了一些主要流程也是能够提前发现问题并且解决的。当时有好几个问题是因为数据缺失，原来一些必要的数据或者有关联关系的数据丢失，或者某些module下的小业务的数据没migration过来导致的，这些完全是可以在界面上看得到的，完全是可以提前发现的。

（2） 针对较难发现型。这个可以通过QA Test提前发现一些，或者在之前就准备一些监控作用的sql脚本，定义一些数据规则，来扫描整个数据库中的表，看数据是否有缺失或者其他异常情况，准备的越详细，就越容易提前发现更多的问题，把影响降到最小，不过做这个事情要考虑成本，可以先粗粒度，后期不断迭代添加业务数据规则。

（3） 针对所有。提前现在QA或者UAT环境先尝试migration，如果公司允许的话，然后把测试做足，之后再在生产环境上做migration。

（4）针对所有。针对migration的代码做code review或者pair去开发，提高代码质量，最好是懂业务的开发一起去做。

不然，会导致对用户造成很多困扰和数据出错，进而导致整个业务混乱，而且有些雷没发现，之后爆炸的时候可能就是致命的了。

5. 测试

   5.1 项目Migration（迁移）之前的测试

   由于测试不够，导致迁移后用户指出主要功能的UI出现了点问题，虽不影响功能但是确实看着难受，对用户有影响，如果用户量比较大，那么就会被疯狂call，而且会降低用户信任度等。

   出现问题我记了下来，link如下：https://blog.csdn.net/spfLinux/article/details/106577028

   总结了下，出现这个问题，主要有以下几点：

   （1）在测试场自己没仔细测，对比测，不重视UI测试。另外，用户经常使用的是IE，自己测试的时候用的是chrome，没注意用户使用习惯；

   （2）感觉没有功能的增加，只是迁移，不需要用户参与，其实为了以防万一，或者其实是可以让用户去测试的，因为平台和环境问题都可能导致某些变化，多找一些人测，找用户来测，基本上是可以提前发现的。

   （3）而且这次只是出现UI问题，但是如果上线后出现某些重要的case走不通，那就真的坑了，所以认真测试以及找用户测试真的有必要。哪怕只是Migration。

6. 请找到Root cause

  6.1  应用无法连接新版本DB

       这个应用的技术架构很旧，是通过powerbuilder去调用oracle client的配置信息进而连接oracle DB的。我们升级了DB版本，我这边尝试了新版本oracle client去连接，但应用始终无法正常连接到oracle DB，我以为是软件技术太老需要升级，就找第三方去升级，隔了一个月，另外一个同事发现是我使用的oracle client是64位的，其实应该是32位的，因为之前就是32位的。而我们后面又试了32位的client就可以连接到新DB，然后我就被批了，因为没找到root cause，造成不必要的误会。我想当时如果拉同事一起，可能这个问题就很快解决了，当时我自己已经认为是软件本身的问题了，急着下了解决，我想以后尽量找到root cause。

  6.2  call不通第三方API

       最近发现call第三方API全都失败了，我当时没仔细看log，而且周末第三方在维护，我这边刹那间就认为是第三方的问题，所以就急急忙忙找第三方，让他们去找问题。结果第二天其他同事一看，这个根本就不是第三方的问题，因为我们API就没call出去，是在内部就失败了，我后面仔细看了下log，还真是，就又造成了误会。后面查到是因为公司安全软件的升级导致这个API被block了，放开就好了。这里也犯了没仔细找root cause的错误，自己真的不能着急了，要先仔细的准确的找到root cause再下结论，否则真的会造成误会，真的没必要而且给别人的印象也比较差。