之前〈為什麼強如大神也會寫糞扣〉的瀏覽次數明顯比其他文章高，感覺大家對於軟體工程相關的論文題材也是滿有興趣的，所以今天也來挑一篇論文來和大家聊聊。這篇論文的題目是〈When and Why Your Code Starts to Smell Bad〉，由美國威廉與瑪麗學院的 Michele Tufano、Denys Poshyvanyk、義大利 Salerno 大學的 Fabio Palomba、Andrea De Lucia、Sannio 大學的 Gabriele Bavota、Massimiliano Di Penta、Molise 大學的 Rocco Oliveto 所發表。

這篇論文主要是從 200 多個不同軟體生態的開源專案變動紀錄中去調查壞味道是什麼時候被開發者留下來的，並探討其產生的背後原因。其中透過程式探勘 50 萬以上的 commits 以及透過人工分析之中的 9164 個。

這份論文的研究問題正如標題所述有二：

• RQ1: When are code smells introduced?
• RQ2: Why are code smells introduced?

先從結論與大家分享，實際研究方法就請有興趣的朋友自行看論文了。為了避免我的理解或是翻譯有讓大家誤解論文的可能，我也附上原文的敘述。

1. 程式碼通常在被建立時就已經受到壞味道的影響了。

2. 因為維護和持續變動而開始發臭的程式碼的度量趨勢，和乾淨的程式碼的度量趨勢有所不同。

3. 雖然正如預期的開發人員通常是在實作新功能或者改善現有功能時留下壞味道，但我們仍然發現有 400 個案例是在重構時留下壞味道。

4. 新手並不是留下壞味道的主要原因，在工作量過重以及沈重壓力下的開發人員更容易在程式碼留下壞味道。

5. Most of times code artifacts are affected by bad smells since their creation.

6. Code artifacts becoming smelly as consequence of maintenance and evolution activities are characterized by peculiar metrics’ trends, different from those of clean artifacts

7. While implementing new features and enhancing existing ones are, as expected, the main activities during which developers tend to introduce smells, we found almost 400 cases in which refactoring operations introduced smells.

8. Newcomers are not necessary responsible for introducing bad smalls, while developers with high workloads and release pressure are more prone to introducing smell instances.

從第一點的結論我們可以知道壞味道在程式碼建立時就已經產生了，所以我們在開發軟體時應該要更重視在新增程式碼時的 Code Review，並且在有壞味道時即時提醒，若是不能當下修正，則應該要記錄下來以作為日後還債的待辦清單中。

根據第二點結論我們也可以透過 CI 幫我們注意論文中提到的某些軟體度量，並在容易出現壞味道的趨勢出現時提醒團隊要特別留意，並在 Code Review 時仔細檢查。

第三點結論則讓我們暸解對於重構的變動亦不能掉以輕心，畢竟在重構時留下壞味道的案例也是有的。

最重要的，第四點印證了〈為什麼強如大神也會寫糞扣〉提到的組織對開發者寫出壞味道的影響，我們應該要避免給予開發者過重的壓力以及超出負荷的工作量，這樣才能減少壞味道的產生，增加軟體的品質。

由於時間與篇幅有限，我先分享到這邊，這幾天有多餘的時間我會對於這篇論文理解與大家分享。但是畢竟我所講的是第二手資料了，還是再次建議有興趣的同好去直接閱讀這邊論文，我在這邊分享的目的也是為了讓更多人暸解到這篇論文與引發興趣。