2018-04-23
今天面了一个很不错的女孩子,面试完之后觉得深度不够,没能让她通过面试.
整个下午一直很内疚,怀疑自己是不是做了一个错误的决定.
工作7年,一直在创业公司,接触到的业务比较简单.对多线程、并发相关的了解不多；mysql的了解限于简单的sql操作；dubbo，spring的了解限于使用，底层的内容未曾主动了解；算法一般，询问给出的排序算法能否再优化下的时候，回答说自己算法不太好。
知道的东西包括：通过sychronized方法做同步，使用redis做并发控制，Collection的相关子类，HashMap的底层实现，设计模式知道几个，手写了单例模式，但未考虑线程安全，提示后做了修正。
恩，整体总结下来就是一个踏实性格好的女孩子，平时对技术追求不高，满足于平时的工作所需。
回来跟同事讨论了下，他的看法是可以满足要求，我怀疑自己是不是要求太高了。一个工作7年的java开发，知识积累依旧如此浅说明了什么问题呢？我在面试过程中应该看哪些方面呢？不同的面试官对自己期待的候选人都有不同的要求，既然是一面的面试官，考察的点当然是技术为主，我需要针对候选人的工作年限期待他具备相应的能力吗？ 面试这么多次，这是唯一一个让我纠结的候选人，踏实、负责，只是限于自己的工作经历未能有所提升，很可惜。
也给自己提个醒，不要受限于自己所在的平台，要多多关注技术的发展，不断提升自己。当所在的平台无法再匹配自己的能力的时候，考虑给自己更大的平台。
2018-04-12
今天测试出现的bug
问题出现时间在于自测完成后
问题出现原因是拷贝一个方法调用的时候，未修改调用参数
所以问题的出现在于做了错误的修改，而且由于自我感觉改动较小，未在重新跑单测，导致问题出现在QA环节；而不是自测环节
2018-03-16
上午负责的定时任务同步数据失败,失败原因有两个:
- 贷后和催收的定时时间重合,导致数据库压力过大
- 贷后的某个字段是varchar类型,催收以数字取出;但某条数据异常导致类型转换失败
暴露出来的问题:之前统一对各个方法加了异常处理,但唯独漏掉了出错的方法,导致后续的数据同步无法进行.或许当初大意觉得不会出问题,所以没有加;此次问题带来的教训就是:应该首先考虑如果出错会造成什么后果,而不是出错的概率有多大.
同时下午帮另一个同事查问题,也是数据同步的问题,其中一个关键字段没有更新,导致线上出现问题,且发生连锁反应.最终发现是一个ifelse中缺少了赋值操作
在查看代码的过程中,能明显看出来代码结构和设计的问题
- 各个ifelse逻辑嵌套,且麻烦的是条件判断使用了简单的比较判断,未做一个逻辑上的封装,所以在跟踪代码的时候只能依靠注释知道各个ifelse分支的走向
- 代码属于纯粹的堆砌,未做逻辑的整理.为了处理一种情况,需要跟踪到各个ifelse的最里层代码
总结下来,好的不易出错的代码首先逻辑上是清晰的,各个处理流程要做清晰的划分,分到不同的函数处理中;同时,避免过多的ifelse逻辑判断,必要的话做函数封装,让函数命名来解释代码逻辑
2018-03-15
下午修改个数据同步的问题，问题出现原因：关联表查询的时候，其中一张表没有数据，导致后续与其关联的表均无法查出数据。为了最终取到数据，需要修改关联的表。问题来了，我以为只是修改下join的字段，所以修改后没有测试就提测了，后边也没有再想过这个事情。晚上上线的时候才忽然想起来，插入的时候没有对这几个缺失的字段做更新，所以重新执行定时任务，虽然缺失的字段可以查到，但这些字段并不会被更新在数据表中。
在这个问题上，反思下我自己处理问题的过程，我只看到了出问题的点，并很快修改了出问题的地方，但是我没有对这整个过程做一个梳理。为了让缺失的字段更新到数据库，需要查到相关字段值，然后更新到指定的数据表中，但显然，我忽略了后边的更新。往往人在精力分散和着急的时候，对一个问题的考虑会缺失一部分，后边要引以为戒，不管多小的点，都要考虑到其所在的整个过程。
2018-03-08
昨天上线很不顺利，背景情况是：先后有两个分支开发，且第二个分支的开发需要依赖第一个分支的功能，所以第二个分支是从第一个分支中copy出来的，且第二个分支修改的内容和第一个分支的功能有重合。在第一个功能开发完成之后，从其上拉取第二个分支做并行开发，此后第一个分支在测试上线后又做了各种修改，上线完成之后,第二天第二个分支随之上线。在第二个分支上线过程中出现的问题，暴露出来我的两个问题：
- 过于自信。对上线过程中出现的问题做修改后，没有足够谨慎地做好测试工作；有时候测试出现的问题可能由于急于修复而忽略掉其他可能的问题和影响。
- 对deadline太过于看重而忽略了上线质量。此次第二个分支上线前需要合并第一个分支的代码，此时两个分支已经有不少差异，虽然自己很紧张地完成了合并工作，但并没有时间再做完整的测试和代码diff。以后应该转变下工作思路，不管什么时候还是要保证上线质量，如果有上线风险要及时提出来。此次上线虽然属于预上线，本意确实是要早早上线做线上验证，但是上线出现问题这个事情会影响到别人对自己的信任，要尽量避免这种情况。
- 最后，在估计工期的时候要充分考虑功能的修改点和其他因素，尽量保证估期准确，按时完成。这个后边再总结下估计工期需要考虑的因素。