Bug记录、归纳

之前若干
不要完全依赖WEB端/移动端，期待他们传正确的值；
第三方接口调用是否捕获异常取决于业务有没有这个必要；
不传有默认值或者是空值，不一定要要求前端一定传；
接口考虑版本兼容处理，实在区别很大，可以升版本。

----------------------------
2017年8月1日
新增字段，需要考虑关联影响，比如说一个模块加了一个新的字段，那么涉及的功能，比如复制，是否需要把新字段考虑进去。

----------------------------
2017年8月2日
返回给前端的值不是最需要的值。比如订单记录中返回给前端当前商品价格，而不是下单时的价格，虽然移动端可以从数据中计算出来，
但是这时候的价格就应该是购买时价格，当前价格显示没太大意义；
数据需要考虑到是否做一定的隔离，包括项目的，或者是用户的，不然很容易造成不该看到的数据被看到。

----------------------------
2017年8月3日
写了抛异常的语句，要看下对所以引用这个函数的地方有没有影响。支持扩展是好的，但是扩展的影响也要多注意。
使用Git，从release到master，需要同时合并到dev

----------------------------
2017年8月4日
看起来完全一样的请求，实际上可能还是有细微区别的，比如今天碰到的一个header有指定Content-Type，一个没有。结果一个成功，一个失败。

----------------------------
2017年8月5日
设计方案时，尽量考虑简单，可靠，可控。

----------------------------
2017年8月7日
子查询的性能，大部分情况下不如连接。

----------------------------
2017年8月9日
Redis值的设立如果是对象最好包含键中的关键信息，便于如果日后需要批量取的情形。
当顺顺利利的开发完成后，发现有需求变更，这时候要改代码，就要注意影响范围了，
最好能通过脑图梳理下，直接埋头做的后果，就是可能又出bug啦。。。

----------------------------
2017年8月10日
相比其他方式，单元测试是比较好的提升质量的方式。

----------------------------
2017年8月11日
差点坑自己。发预生产用功能分支，这步本身就是不对的，还好有比较下代码，重新合了分支，正常流程就应该用master来发布预生产和生产！

----------------------------
2017年8月14日
之前为了提高性能，一段程序直接改为从redis中批量获取键。但是忽视了有些键还没有缓存到到redis的情形，这种情况需要再请求一次。因为之前依赖spring的cache，认为肯定都有cache，其实不一定，可能编辑的时候，就会先清除cache的。所以思维还不够严谨，考虑要更全面一点才行。

----------------------------
2017年8月15日
线程内部变量计算是不会有线程问题，当多个线程有一起执行数据库时，就要警惕可能出现死锁的情况。

----------------------------
2017年8月16日
对于需要对生产数据做大数据量处理的版本，需要把计划提前安排好，不然就会很被动，可能导致项目发布延期！

----------------------------
2017年8月17日
定位Bug的思路都是差不多的：相似的直接根据历史经验判断；其他情况：1、寻找和梳理线索；2、根据线索顺藤摸瓜找到大概位置；3、适当假设；4、验证假设。重复3~4直到问题原因查明。

----------------------------
2017年8月22日
编写v2版本的接口时，要注意如果v1版本已经实现的功能，如果需要兼容，也要补充进去。

----------------------------
2017年8月25日
从二轮到预生产需要先合到master再发布，为的是后面发布可以省时间，一点点时间累积起来还是挺可观的。
测试驱动开发这件事情，其实当你实际去做的时候，才会发现对提升软件质量的作用。比如开发时就要考虑测试的点，用测试角度看待功能。比如测试支付，支付这件事情上基本在QA那里是不会失败的，那么要测试支付失败的场景，该怎么办，就需要开发配合调整程序，加入开关等。

----------------------------
2017年8月29日
对于剩余天数这种数据不要直接返回到期时间给前端计算，因为前端依赖的本地时间不一定是正确的。

----------------------------
2017年9月18日
字不如表，表不如图。

----------------------------
2017年10月14日
技术方案一定是基于业务基础，服务于业务，并且衡量过投入产出比的。
细节是魔鬼。
优化是无止境的。
----------------------------
2017年11月1日
如果将原来扁平的sql拆成多个连接的方式，要注意数据集是否一致

----------------------------
2019年1月17日

代理别人接口的时候，要注意看下有什么限制，比如发短信这个....被限制1分钟内1个ip只能发一条

----------------------------

2019年3月6日

预生产库同生产库时，执行生产脚本的时候，需要严格检查，否则可能出现破坏性变更，造成生产故障。

----------------------------

2019年3月20日

对于有一定时效性的数据，可以保存到Redis中，设置有效期，自动删除

----------------------------

2019年4月26日

今天定时任务从凌晨开始跑，但是到中午还没有结束。任务是对表做查询，再做统计。由于被统计的表随着用户高峰期数据量变大，数据已达千万，有了性能问题。由于查询当时连的是主库，于是线上慢查询变多，紧急停止了任务。这事告诉我，1：大数量的任务不要直连主库查询，而是要走从库；2、千万级的数据统计，走mysql是慢的，应该利用现在各种大数据平台来计算。

----------------------------

2019年5月15日

今天收到bug，关于一个字段为空，导致查询不到结果。原来的时候对jpa保存机制没反应过来，以为如果数据库设置了默认值，那么插入库的时候会没传值或者null应该会用默认值。但是这个数据库没设必填被插入了null值，说明就是按null值进行保存的。以后初始字段值，需要注意到字段的类型初始，在存储的时候进行拦截。

----------------------------

2019年7月5日

特殊字符&，导致URL请求中接收方获取数据不完整。提醒在遇到网络请求时，必须要注意转码问题。

----------------------------

2019年7月26日

针对已有方法或类的修改，一定要考虑他之前所有的引用，否则改了这边影响那边，会给自己挖坑。

不要让showcase形同虚设，要发挥起作用来，没有show过，结果果然出错了。

----------------------------

2019年9月6日

在设计API的时候，考虑变化，是否有封装变化，是否具备较好的可扩展性、可维护性。

----------------------------

2019年11月1日

调用第三方接口需要catch处理。不然针对对方接口可能出现的502，504等就无法记录，或者直接导致业务异常。

尽可能标准化的做一件事情，你不知道哪一天标准就起了作用，减轻了扩展改造的压力（保存json与tostring()的选择）