2015_ICSE_When and Why Your Code Starts to Smell Bad

觉得这个文章还不错，无论从试验的规模，从github上搞来了从属于3个ecosystem（Android，Apache，Eclipse）的200个projects。从commit history中抽出了50多万的commit，用DECOR分析了那些bad smell commit。这里的bad smell文章就从已有定义的多种bad smells中选择了5种，分别是实现各种功能class，没有参数的很长的函数，很多属性被公开访问的类，属性很多但函数很少的类，高复杂度的。对这些bad smells，就去分析when and why these bad smells are introduced。

对于when，作者首先用DECOR加一些启发式规则，找出导致smelly bad的commit，这里有注意的是因为一个code变得smell bad可能是由多个commit逐渐导致的，比如一些很复杂的类。好像因为这些，所以才加了一些启发式规则，不能直接使用DECOR的结果，不过工具本身的使用，就要考虑到工具的precision和recall如何，这里，作者在threats to validity里提到了这点，说到了其P和R，以及讲到了人为去check，所以数据估计还是蛮可靠的。通过分析，发现对于when bad smells are introduced这个问题，作者得出的结论是，很多bad smells在files一被创建出来的时候就被introduced了，当然对于一些比较复杂的类等，是会经过好几次commit才会形成bad smell。

对于Why，这里的也就是考虑bad smells被introduced的原因了，我感觉一说到原因这一块，差不多就2类，一类大家都不知道原因，自己通过人为去看数据，然后分析总结出一些原因。另一类，就是前人通过一些努力已经发现了一些可能导致某一现象的原因，然后，我们呢，就是利用前人已有的研究，用我们自己大量的数据去验证下，看是不是的确如此。本文就属于后者，作者借用前人说的一些原因，将其分为3类tag给commit贴上，一类是commit-goal（bug fixing，enhancement，new features，refactor），一类是project status（一个是release压力，用commit引入的时间是release前1天，前1周，前1个月还是more，另一个是project start up的时间，用commit在project正式开启后多久引入的，是1周，1个月，1年还是更久），最后一类是developer本身的状态（是否是new developer，其对code的ownership如何，工作负载workload如何）。将所有的bad smell commit贴上标签后，通过统计数目，给出结论。结果发现：

1）很多bad smells是在做enhancement和newfeatures引入的，refactors本身居然也有很多，这有点让人意外，一般以为refactor都算improve code quality的。所以作者觉得可能需要更好地工具来支持refactor。当然，最大的大头还是enhancement（第1位）和new features（第2位）。

2）很多bad smells在project release前1个月引入的可能性最大，且在项目开始1年后引入比较多。

3）new developers并不会引入大量的bad smells code，反而是那些比较experienced和对code ownership比较高的developer引入的bad smells code多，当然，作者并没有说experienced developer更会引入bad smell code，因为Zeller原来在why system fails的书里就说过，所谓能者多劳，越牛逼的人承担的任务更重也更艰巨，所以犯错的可能性也许就越大，但毕竟作者没有去深挖，为什么，所以，估计也就不好意思对experienced developers做一定的结论，只能通过数据说一句很多bad smells code并不是由新手引入滴。

4）还有一个结论是，作者发现对于clean和bad smell code，其在一些metrics上还是会有显著的不同的。具体的作者搞了个Mann-Whitney Test。不够这个具体怎么搞得就不懂了。

以上！

觉得还不错，文章。

2015-07-17

zou@Home