在TDD循环中，重构(Refactoring)是不改变行为而改变内部结构的动作，保持测试常绿。而变形(Transformation)是改变内部实现来使测试由红变绿。这些变形的变化使代码形式从特殊specific到一般generic。
Uncle Bob的一篇文章。http://blog.8thlight.com/uncle-bob/2013/05/27/TheTransformationPriorityPremise.html
中用了bowling game kata 和 Prime Factor kata来解释。
在教练敏捷团队的过程中，一些团队反映“某些用户故事不好拆分，无法在一个迭代内完成”。对于这些故事，一些团队的做法是先指定资深人员作为“设计师”，他从“需求分析师”或业务方拿到需求后，花上1个迭代的时间进行“设计”，然后由他将编码任务进一步分配给“开发人员”，并且负责验收代码。这些故事往往就会持续1~2个迭代才能完成，甚至还来不及测试。
单元测试(unit testing)已经越来越得到广大开发者的认可。作为低成本、速度快、稳定度高的自动化测试手段，单元测试可以在类和函数级别对代码进行质量守护，有助于避免尴尬、耗时的错误。当然，相比功能测试(Functional testing)和端到端测试(end-to-end testing)，单元测试能够寄予的产品级别的信心要略低一些，因而各个粒度的测试应该是相辅相成的，互为补充。
常常听到一些组织要求开发团队提高单元测试覆盖率，换来的却是怨声载道，或者是一堆应付差事的垃圾测试（没有断言的测试，都见过吧）。尽管，低测试覆盖率意味着对质量的信心不足，但是，单元测试覆盖率真的要达到100%才好吗？
QClub天津系列活动即“精益创业周末”主题沙龙，于6月28日在天津夏日荷花酒店举行。来自某国际知名户外运动品牌的市场运营总监柴婧女士和来自百度PMO的李忠利老师为大家带来了分享。天津软件沙龙作为协办方提供了会议组织和服务。
近一两年，O2O（Online to Offline）的概念炒的火热，不管是BAT互联网大鳄，还是秉承精益创业的理想者，甚至传统产业的觉悟者，纷纷跳海。前几年惨烈的团购大战之后，去年的打车软件烧钱补贴还历历在目，誓要改变人们的生活行为。如今战火继续蔓延，保姆、洗车等领域也都卷入其中。
远镜投资的金戈先生，最近家里恰好有保姆钟点工的需求，于是他选用了一款叫做e家洁的app软件。结果他大呼慎用啊，因为这软件真是太“巧妙”了。
他发现，一开始用的时候阿姨几乎90%以上都是好评。定了服务之后：
1.你定的时间他们来不了，会和你重新约时间。
2.你定的人来不了，需要重新指派。
3.指派的人到时间完全不来，还联系不上。
4.投诉后重新派单，居然没到的这单显示完成，要求我评价。
5.该评价不能点差评，文字无法录入自动清空，选1星提交会自动返回4星好评。最终此单会成为默认好评。难怪大部分好评都是所谓的默认好评。
目前的本地生活服务o2o大多是从小时工、保洁等家政服务入手，进一步试图进军家电维保等领域。无论是e家洁、95081、云家政之类都是如此。尤其从小时工领域更易入手，以互联网+LBS的模式一方面为用户提供足够多的选择，另一方面通过评价体系尽可能的消除信息不对称，此外还依赖LBS尽量提高服务效率减少路程奔波所带来的时间浪费。
听上去很美，实际上很难。几大难点：
1.家政服务员本身管理困难，服务质量难于标准化评测和监督，与用户交互界面时间很长，需要培训的关键点太多。这就导致，如果采用纯平台的轻模式（类似95081），则服务质量保证难度较大。而如果采用员工均自聘的模式，则扩张受限，员工人数、用户规模、用工效率也易成为难以解决的矛盾，管理成本也会居高不下。
2.家政服务容易“短路”平台。用户当发现来的家政服务员很满意的时候，往往会选择直接联系服务员（尤其是遇到e家洁这种，很可能你约的服务员来不了会安排其他人的），而如果用户用的家政服务员不满意的时候，用户干脆就不会继续用这个app了。
3.利润微薄，作为中间商家政服务app目前几乎都是烧钱在做。在一个本身客单并不很高的行业，做平台商哪怕收取中介费用是否能支撑起一个足够有规模的品牌令人怀疑。这也是诸位竞争者不断进军新的领域的原因之一。当然，BAT或投资或合作插手其中，自有着大公司o2o战略的考量。
所以，金戈先生觉得本地生活服务o2o从家政入手未必是个好想法，虽然入手容易但想要做好有以上种种问题。还是找个高客单，低频次，易于标准化考量工作结果，用户对消除信息不对称和质量保障要求更高的事儿更靠谱。例如家庭维修安装，汽车保养维修等等。
Functional programming leads to deep insights into the nature of computation. – Martin Odersky
近日软件匠艺小组的朋友用函数式编程的方式重新实现了一个古老的Kata练习题:FizzBuzzWhizz，用了很多种语言及其特性，非常精妙。这是一个软件匠艺的文艺复兴时代。
原帖见https://codingstyle.cn/topics/100
FizzBuzzWhizz详细描述请自行查阅相关资料。此处以3, 5, 7为例，形式化地描述一下问题。
r1
+ times(3) -> Fizz
+ times(5) -> Buzz
+ times(7) -> Whizz
r2
+ times(3) && times(5) && times(7) -> FizzBuzzWhizz
+ times(3) && times(5) -> FizzBuzz
+ times(3) && times(7) -> FizzWhizz
+ times(5) && times(7) -> BuzzWhizz
r3
+ contains(3) -> Fizz
+ the priority of contains(3) is highest
rd
+ others -> others
借助原帖的测试用例，我用python语言也练习了一把。本来想引入Pipe库用管道式的方式写，可能会取得一些方便，但想想还是用原生的语法来做吧。
