摘要:
记录周反思
反思:
- 现阶段对于Tianmu引擎功能的单元测试,集成测试都不完善, 只有MTR的SQL句子的黑盒测试, 而且现在MTR的SQL句子测试也不够完善。建议考虑开发Tianmu引擎测试框架, 不仅仅是用黑盒的做法使用SQL做测试，而是对具体的类和函数级别进行测试。这样不但能证明自己逻辑的正确，也便于功能和逻辑的升级和优化重构。但是问题在于完善的测试需要至少两倍于开发代码的时间。最近的项目方反应的问题很大程度上是开发功能后由于测试时间匮乏导致压缩测试，未提前发现。但是更进一步想, 这是因为在写的测试用例就缺乏更多的场景的覆盖度。要么做的很快但是错的很多，要么问题很少但是需要花费大量的时间填补各个场景的逻辑。怎么做不但取决于技术的完美主义还取决于现有资源是否允许。
- 承接第一条, POC的项目和中科院的项目暴漏出来的问题, 很具有代表性，如何在后续避免再出现类似的问题。我的建议，一是要理解mysql的代码和Tianmu引擎代码的逻辑，不但要知道代码在做什么，还要知道为什么要这么做。二是要留足充分的自测时间，要对做的功能有充分的认识，对涉及到的方方面面都要进行测试，现阶段无法做到自动化的测试，那么就用手工模拟场景做测试。
- 缺乏一个类似禅道一样的可视化任务管理系统，类似于禅道，如果要把github的issuse当作类似禅道的BUG单和任务单一样的东西，那么这玩意就必然会不断的累积，由于精力和人力问题存在大量待排期的需要解决的问题和要解决的需求。不过如果是将产品商业化, 那让客户看到内部这么多问题, 对客户的信心有影响, 从商业上考虑在issuse上不应该放太多未解决的BUG。还是和上边测试覆盖度面临的问题，资源，最大的资源就是时间，现在的代码的成熟度必然会爆发出大量的问题需要解决，而解决这些问题都需要时间，时间有限，那就按优先级来定位，优先级低的就等排期。
- 从问题中，反思做事方法，反思产生问题的原因，反思如何防止未来的发生。只有从战斗中才能学习战斗，不是从实践中反思出的东西，无论是什么经验，都是自我娱乐。