一個 Singleton 引起的 DB 爆炸

我是向來自認爲本身是編程高手的。若是又是 Python，我簡直是頂尖高手啊！然而，我這「頂尖高手」卻被本身坑了一把，還把另外一個高手給忽悠了。

這一切，都得從一個 Singleton 提及。

Python 的 Singleton 很容易，不過是

class Singleton:
    ob = None
    
    def __new__(cls):
        if cls.ob is None:
            cls.ob = SomeThing
        return cls.ob
複製代碼

然而，我寫成了

class Singleton:
    connetion = None
    
    def __new__(cls):
        if cls.connection is None:
            return NewConnection(PoolSize=xxx)
        return cls.connection
複製代碼

你看到問題了嗎？這根本不會重用啊！！！

這個代碼是數據庫鏈接代碼，致使每一個數據庫請求都開啓一個新的鏈接。我一分鐘上百上千個左右的請求。數據庫鏈接爆炸。

同事在代碼審查時說：「你這個好像不對啊？」

我：Python Singleton 就是這樣的。

同事：你肯定？

我：我肯定，我都 Py 大師了。

同事：好像確實是錯的。

我：不不不，你多慮了。

同事：好吧，上線。

我真是系統性大忽悠啊！

若是說這算是智障，接下來還有更智障的。

我實際上是有測試的，測試結果顯示這個文件的最後一行

return cls.ob
複製代碼

根本沒有跑過。可是由於文件小，有93%的覆蓋，我就以爲沒事，就忽略了！

我靠，該文件總共就這一個class一個方法！其餘全是import, 93% 和 50% 一個意思好嗎！並且，是整個後端都依賴的代碼，很明顯得 100% 才行啊。

我竟然就忽視了很多天，直到數據庫爆炸才 debug，並且竟然花了 3 個小時！

我去檢查各類線程安全性（咱們用的 coroutine，根本沒有線程），併發安全性，內存問題。。。

MDZZ！

---

固然，這些無用的檢查讓我發現了幾個部署層面的優化空間。

如何避免

給不一樣文件模組設定最低測試覆蓋率。 好比，關鍵代碼必須100%，中間件95%，用戶層代碼90%之類的。不一樣 Layer 的代碼的測試要求是不同的。即便測試都過了，測試覆蓋率不達標也算失敗。

並且，必定不要人爲檢查覆蓋率，用工具自動化檢查，成爲 CI 的一部分。