為什麼很多應用的改動記錄里寫的都是修正「已知」問題」？

01-07

難道還能修復未知的問題嗎？

It is common practice for software to be released with known bugs that are considered "non-critical" as defined by the software producer(s). While software products may, by definition, contain any number of unknown bugs, measurements during testing can provide an estimate of the number of likely bugs remaining; this becomes more reliable the longer a product is tested and developed. Most big software projects maintain two lists of "known bugs" – those known to the software team, and those to be told to users.

[citation needed]

The second list informs users about bugs that are not fixed in the current release, or not fixed at all, and a workaround may be offered.
A software publisher may opt not to fix a particular bug for a number of reasons, including:

A deadline must be met and priorities are such that only those above a certain severity are fixed for the current software release.

The bug is already fixed in an upcoming release, and it is not serious enough to warrant an immediate update or patch

The changes to the code required to fix the bug are too costly, will take too long for the current release, or affect too many other areas of the software.

Users may be relying on the undocumented, buggy behavior; it may introduce a breaking change.

The problem is in an area which will be obsolete with an upcoming release; fixing it is unnecessary.

It"s "not a bug". A misunderstanding has arisen between expected and perceived behavior, when such misunderstanding is not due to confusion arising from design flaws, or faulty documentation.

來源：https://en.wikipedia.org/wiki/Software_bug

簡單理解是：

軟體是可以帶著 bug 發布的（比如趕 deadline 或問題不重要不緊迫沒有及時修復等等原因），「已知問題」是開發者已知，或者需要告知用戶的。於是，「known bugs」就成了一個「專業術語」了，含有「我們已經知道有這 bug 了，你們別再反饋了啊，後續版本再修復」的這個意思。這個「專業術語」直譯過來就是「已知問題」，這絲毫沒有和「未知」對立的意思，理解為「專業術語」就好。

「未知問題」是無法修復的，只能避免。甚至，「未知問題」都無法存在，因為一旦被發現存在就立馬變成「已知問題」了。

修改總是需要理由的吧，總不能是「今天閑得無聊重新編譯了一下」。

而且必須是合理的理由，不能是「經理指示要加強用戶隱私收集，我們增加了讀取並上傳通話記錄的功能」(實際上就是！)。

最合理也是常見的理由就是修復漏洞了，其他各位也提到帶著漏洞發布也是可以的。但是，多數情況下漏洞的成因和機理複雜，普通用戶難以理解(俗稱：以你們的智商很難和你們解釋)，因此只是籠統地說「修復漏洞」，又因為漏洞這個字眼使人產生不好的感覺，以為是碼農糊弄交差造成的(事實似乎就是這樣的)，改成「修復了一些問題」顯得更政治正確。

至於「已知」，可能是暗示「我們一發現問題就馬上修復了，所以更新如此頻繁，不是在做小動作，你們不要懷疑啊！」

樓上正解，黑話，已知，就是知道很久了

潛台詞是，這次緊急問題不多，所以從歷史遺留問題列表裡挑了幾個隨便改改

谷歌有一次升級chrome，changelog寫的是升級了版本號

用戶不需要知道修復了什麼BUG，而且列出一堆BUG對用戶並不友好，對產品也不好，哈哈。

所以，修復了BUG，一般是本地有更新日誌保存，但是線上對用戶就是修復已知問題了。

另外，產品更新加入了更多廣告，也不會提示用戶，如果只是加廣告，發布時寫的優化用戶體驗

未知的問題修了也不知道啊。

上面是吐槽。

因為在實際的軟體開發中，一個Bug的出現往往牽扯到很多方面，所以修復的位置可能有很多。

一般而言，Bug可能由幾種方式被提出：

1. 用戶使用時出現的Bug；

2. 產品測試時發現的Bug；

3. Code Review時發現的Bug。

針對第一種Bug，一般比較容易在修改日誌中描述，因為有明顯的現象發生，因此就能夠明確地給出修正的結果。

對於第二種Bug，如果說涉及到的測試用例比較複雜的話，其實是很難用幾十個字描述清楚的，總不能在App里寫上「如果用戶在xxx情況下點擊xxx，然後跳轉到xxx頁面再輸入xxx，會導致xxx數據出現異常，在xx分鐘後軟體會有xxx現象發生」這樣的描述吧？用戶也肯定不願意看到這麼莫名其妙的修復內容。

而對於第三種情況可能就更加複雜，往往會在非常特殊的情況下發生，也不可能將那麼多涉及到軟體內部結構和關鍵思路的內容呈現給用戶。

所以當一個問題很難用簡短的語言描述清楚時，程序員們也就只能說這些是「已知問題」了。

當然，其實可能省略「已知」，說「修復了幾個問題」。但是這樣描述說起來不那麼順口，所以大家也就習慣性地說「修復了幾個已知問題」。

當然有可能就是純粹的懶。

難不成未知的問題他都能修復？

修正的是已經知道，一直沒空，現在有空改的問題。