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

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

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

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

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

用 vi

Cloud Foxpro

想起那个切蛋蛋的笑话

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

让她分析一下为什么坏的这么快？可以从哪些方面改善质量。

晕，看错城市。当我没说

宝尊

TDD 流程里写了测试还没实现的时候，非要 2b 兮兮的先运行一遍测试失败，再开始实现。就是为了简单的测试测试用例本身。
写了一段代码后原来失败的测试通过了。说明这个测试自己是和这段代码行为有关系的。
当然未必严谨，但是基本够用了。

@Acheron 人，以及人会犯错误的本性也是偏离代码本质的。在人工智能还没发展到代码自己进化那天前，只能暂时依赖不完美的程序员来写代码。
不论 review，注释，unit test，都是为了补救不完美的程序员，避免他们偏离代码本质。
当然如果你认为自己就代表着最纯粹的本质，那当我没说。

方便从 github 上拉开源代码，无缝衔接

挺好的啊，不知道你要优化什么

喜欢的话可以把两个数组改成一个对象的数组，看起来 header 和 data 的关系更清楚一些。

@msg7086 事先写测试也还是容易放过一些边界条件。而且往往边界值是和具体实现相关的。如果你看我这次练习视频后半部分重构提升性能的地方，就会发现代码出现了新的边界值，而原有的测试并不能覆盖。

TDD 只是以自动报错的方式定义预期的行为，自然不能查到非预期的错误。
简单来说 TDD 中的 test 事实上是类似 checklist 里的 check，是帮助开发者更有效开发的。而不是 QA 领域所说的 test