four rules for simple design

紧接着志愿者介绍了four rules for simple design，大致意思是：

编写单元测试，以最少的实现快速的让测试跑通

消除重复

你的代码应该明确的表达你的意图

只写需要的功能，不要过度设计

加入TW之后，对上述几点感触真的很深，尤其是2，3，4，这些输入主要来源于我的buddy。

消除重复

我目前主要从事前端开发，刚进项目组的时候，编写一些和历史组件雷同的组件，本应在历史组件上扩展，我却总想复制粘贴一份，总觉得直接改原来的，万一改挂了可咋办！

我buddy说：这是重复啊，那你想想，这两个组件基本一样，其中一个的业务场景变了，另一个是不是要变？那修改这段代码的人就是双倍的工作量，如果每个人都这样做，让你一个地方改10遍，给你你愿意吗？

嗯，有道理，所以重复是一定要被干掉的，不能老给别人挖坑呀。

写能够揭示意图的代码

前段时间写代码的时候，用了奇奇怪怪的方法做了数据转换，大致就是写这段代码的时候，只有我和上帝懂，写完了之后，就只有上帝懂.......当时code review的时候还理直气壮的觉得自己写的没错，就应该这么写。

直到后来，我buddy和我一起，以另一种思路，重写了那部分代码，条理之清楚让我明白了，写让人能迅速读懂的代码是多么的重要。

此外，“揭示意图”也体现在方法和变量的命名，判断条件的编写，好的命名可以让阅读代码的人更容易理解代码的意图，这样做的直接好处就是为后续维护提供便利。判断条件尽量使用正向逻辑。虽然双重否定表肯定，“我爱你”和“我怎么可能不爱”表达的意思相同，但是显然前者更直观，所以推荐使用肯定句。

拒绝过度设计

这点上我buddy给了我很大的启发，大家都知道过度设计是不对的，如何有效避免过度设计才是关键。

使用TDD就是避免过度设计的有效方式，每一条需求都是一个单元测试，用测试来体现需求，然后以最少的代码让测试跑通，也就是只做测试需要的内容，由结果推实现，当然就不会过度设计了。

你可能会说，不是所有代码都有测试，那当我们不写测试的时候，怎样避免过度设计呢？答案就是：先使用，再准备。我们往往准备一大堆东西，真正使用的时候并不是所有的都会用到。其实可以反着来，我知道我要C，C的前提是B，这个时候再去创造B，以此类推，直到实现功能。

活动才刚刚开始

10点的时候，大家通过报数随机匹配了小伙伴之后，开始了第一个迭代的内容：乒乓结对，最少代码实现测试。和我的小伙伴分析了需求之后，第一回合我写测试他来实现，我的小伙伴来自一个金融公司，对数字比较敏感，在实现第一个测试的时候，他说：我们应该先对传进来的数字做校验，对数字不合法的情况做处理。我想了想说道：我们现在是测试驱动实现，如果要做数字校验，那我们应该有一个单元测试，测试的内容是如果输入不合法，会返回什么结果。现在题目的需求里没有数字校验这一条，所以我们不能写数字校验的测试，也就不能写数字校验的实现，对吧。（这些都是从我buddy那学的，嘿嘿学以致用）他若有所思的点点头，我们愉快的开始了40分钟的“乒乓”。

第二个迭代的主题是：无基本数据类型。这个阶段我的角色是观察员（每个迭代会有两个与会者和志愿者一起当观察员，观察并记录看到的一些好的或不好的现象，在迭代结束的时候和大家分享）。这个过程中我看到了很多东西，语言和语言的碰撞，java, js, python, 还有全世界最好的语言PHP，大家互相指导，互相学习。想法和想法的碰撞，切磋，讨论，互相说服，直到达成一致，开始撸码。

午饭之后稍事休息，开始了第三个迭代：无条件判断，这个过程就是用继承，多态来消除一些条件判断。很巧的是和张铁锤分到一组，于是和他学习了Python，但是没写多少东西，时间都用来讨论了，毕竟太熟了，两个人都不愿意退让......

第四个迭代的主题是：无副作用方法，这个也是我buddy跟我提了很多次的，你改变了方法以外的东西，别人不看这个方法，不会知道你做了什么改变。这个过程中结识了一个从天津赶来的姑娘，也是学前端的，看起来小小的，真的很佩服她，不畏距离和寒风，想想自己早上7点多起床都拧巴的不行，觉得自己弱爆了。活动结束后我们有聊过天，她很感谢这次活动，觉得TW的同事们都热衷于分享，她对TW充满期待的同时，我也对我们成为同事充满期待。嘿，姑娘，我们要一起努力哦。

第五个迭代的主题是：不超过5行的方法，由于时间关系，这个迭代被砍掉了，大家一起做了讨论和总结，由于活动的内容之前我基本都感受过，所以参加此次活动的感受就是把一些思想强化了，不像铁锤哥那样充满新鲜感，他对TDD赞不绝口，对和他一起结对的那位thoughtworker更是崇拜有加，回家后，好像变得更努力了呢。

张铁锤在骚窝