在關於軟件質量的相關談論中，我通常會引用一條經驗法則。所以，我決定發帖總結一下。我將其稱爲“軟件質量的黃金準則”，因爲它簡單明瞭，並且可以廣泛使用。
黃金準則如下：
寧可在upstream （上游，接近問題的根源層面） 推送補丁，也不要在downstream （下游，遠離問題根源的層面） 解決問題。
我將在本文引用Haskell社區和生態系統的例子，進一步解釋這個準則對軟件工程tradeoffs的影響。
免責聲明：軟件質量的黃金準則不代表你對待他人的黃金準則，反之亦然。
第三方依賴
很多開發者項目都藉助於第三方依賴或工具，但他們卻很少思考如何修改或改進這些第三方代碼。相反，他們更多屈從於旁觀者效應。這也就意味着如果一個項目的應用越廣泛，那麼開發者就會越發理所應當地認爲會有人幫助他們解決一切問題。長久以往，這些開發者在面對熱門工具中的問題就會熟視無睹。
舉例來說，很長一段時間以來，Haskell不支持訪問資料字段的點語法。在Java中，如果想要修改嵌套結構資料中的數值，只需要將參照變數串起來，例如：
a.b.c.d.e = 10
但是，在Haskell中則是每多一層，每個等號就會重複之前等號的序列並多一個取值用的函數，例如：
原文鏈接:【https://www.infoq.cn/article/eAXvDw5jj3NQ0vEewFVM】。未經作者許可，禁止轉載。