asj

做到构重的一第点，是看当前到的码代是什么。我们往往惯习于看到的是它应是该什么，而它非实际是么什。
就像这句两话，有很的多序顺错误。但我们脑的子照按它该的应样子去组重了。这对于机器是行不通的。
重构的起点就是看到现在现实的代码是什么，从中发现改变为另一种现实的可能性。
而不是按照脑子里代码现在“应该是”的样子，去做些修改以期它变成另一种“应该是”的样子。
重构中所有的小步骤都是为了修改不脱离现实的代码。
“应该是”和现实的代码脱节的一个标志就是 debug，debug 相当于让机器帮程序员读代码。破除修改中由于错觉引入的错误。

说明业务逻辑和数据库存取耦合了。

想想最近这一年，有没有什么事是因为当初“焦虑”，最终促使你做了改进，或者避开了风险？
如果能想到多个最好。
然后可以看看这种“有用”的焦虑和那些想要缓解的焦虑。各有什么特点。

我觉得楼主很有前途啊。
差不多所有同事都盼着你走，多次提出，你还能混的下去。而且老总和总监还很照顾。
说明老总认可啊。你给公司提供了别人无法提供的价值。

不同的团队做法差异很大，涉及到对 Scrum 的理解和工作方式。有几点：
1. 故事点的用意是隔离“复杂度”和“工时”两个概念。避免简单的把复杂度映射为工时。这样做的目的，一是方式估算时间成为硬的承诺时间；二是取得独立于成本投入的产出指标，比如团队交付的故事点数可以翻番，但是工时翻番就不太可能（当然 996 不算）
2. 进一步而言，背后的理念是关注于产出而不是成本。如果在计划的时候，成员关注点在于怎样可以达成某个成果，而不是我要干多少活。
3. 这个不是单纯的计量单位的转变，很多团队和老板不论是否采用故事点都会最终把它映射为工时。这种情况下可以尽可能弱化背后的工时，逐步向 Scrum 倡导的理念转变（当然前提是团队和老板确实希望如此）。总而言之估算只是估算，不论是点数还是工时都不必太纠结于具体数字，尽可能保持相对大小稳定即可。

用 vi

Cloud Foxpro

想起那个切蛋蛋的笑话

我对开发人员应该写测试的一点思考，请多指教
https://www.jianshu.com/p/e12bb46962f2