TDD 与 BUG 的爱恨情仇（卷四），本系列链表头部请戳 A song of TDD and BUG - 前奏曲 All About Change劝分不劝和Dependency Map历史代码 TDD 改造需要注意的问题Start SmallChoose Your BattleField记得写单测并不是你的目的，减少 Bug 才是，所以我们需要把有限的精力放在收益最大的单侧上。我推荐两种选择写单测优先级的方案： 利用时间局部性：就像 LRU 的思想一下，在最近一段时间修改过的逻辑很有可能在未来一段时间内也需要修改，所以选择用单侧保证这部分逻辑有助于之后的迭代和重构。 “从”新开始：主意是从新，不是重新，也就是暂时考虑放弃之前的逻辑，对新业务使用 TDD 的开发模式来开发。这种比较适合没有时间对老代码进行重构和改造的情况，先对新的业务进行单测，等到业务稳定以后再考虑之前的历史包袱。 查看全文

TDD 与 BUG 的爱恨情仇（卷三），本系列链表头部请戳 A song of TDD and BUG - 前奏曲 副歌不副，FTDD 不 F可能你在想，不是 A song of TDD and BUG 吗？怎么都到了副歌部分了，还没怎么说 TDD。这个可能就要怪我们民国的大师们把 Chorus 翻译成副歌了，明明是最高潮的部分，翻译成副歌总给人一种莫名其妙的感觉，不过也可能是我乐理不精对大师的翻译没有深刻理解导致的。那吐槽吐完，开始讲正事，之前有给过大家一个强烈但不失友善的警告大家应该还记得吧，不记得的可以去复习一下 A song of TDD and BUG - 主歌。那会我说过适合自己的才是最好的，俗话说的好，规则就是用来打破的，只要我们了解了 TDD 的真谛，就可以把它改造成最适合自己的开发模式，我把这些 TDD 的变种们称为 FTDD。那何谓 FTDD，这个多出来的 F 代表什么？其实就是 Fu..，不好意思，是 Fake，也就是“伪 TDD”。那为什么说 FTDD 不 F 呢？因为这个“伪”并不是真正意义上的伪，而是结合了自己对 TDD 的理解和实践的产物，也可以... 查看全文

TDD 与 BUG 的爱恨情仇（卷二），本系列链表头部请戳 A song of TDD and BUG - 前奏曲 FBI Warning我知道你在想啥，但是你想多了，我只是想给你一个强烈但不失友善的警告（Friendly But Intense Warning）而已。在了解 TDD 之前你需要知道，TDD 只是一种开发模式，不是圣经也不是行为准则，我们需要辩证的去看待 TDD，可以参照 TDD 并且结合自己的实际情况选择最适合自己的开发模式，毕竟适合自己的才是最好的。这你可能会问了，刚你还说 TDD 又是最耀眼的新星，又是救世主的，现在咋又说人家坏话。我想说的是，你毕竟还是 Too Young，要我不进行一波商业吹嘘，你可能也不愿意往下看啊，流量称王的时代，我不得忽悠你多看几眼啊。 什么代码需要写单测并不是所有的代码都需要你写单测来保证的，总结起来就是“三个不一个要”： 不给自动生成的代码写 Unit Test（比如生成的 getter setter），我们要相信 Xcode（或者其他编辑器），出了问题是天灾，需要我们单独分情况处理，然后给我们自己处理的代码写单测。 不给... 查看全文

TDD 与 BUG 的爱恨情仇（卷一） 前言这是最好的时代，TDD 的出现终结了 BUG 横行的蛮荒，从此 Coding 世界进入了秩序与光明；这也是最坏的时代，历史的包袱，无尽的重构，博弈与妥协充斥在每个角落。从电脑和编程出现之初 Bug 就如影随形，那只飞到 Mark II 上的 Bug 穿越了大半个世纪，仍是程序员们在梦中惊醒，在镜前流泪的主要原因。那 Bug 为什么会出现？有没可能消除 Bug？ 这是个哲学问题。 Bug的相对性原理有人说 Bug 是一个 Human Error，是可以通过一定的约定，准则和谨慎去避免的。的确, Bug 的多少很大程度上是程序员的谨慎程度来决定的。但是，我先把我的结论放在这， Bug 是无法避免的，也就是说他是一个在排除了人为错误之外的系统性的存在。 这听起来很像给自己开脱（其实就是给自己开脱），但是我是有理（狡）论（辨）支持的。比如之前有人提出来过抽象漏洞定律来解释这个问题，但是这个太笼统，听起来也太抽象，我想用自己的理解来解释一下。首先我们需要定义 Bug 是什么，维基百科中 Bug 的定义是程序错误。我们在这给它一个更明确，更有意... 查看全文