Well，事實來說複雜度上去了以後其實這兩點也很難做到。
任何上了複雜度的軟體最後都是日常log里噴各種warning和error，但是這些warning和error要到你已知發生了問題時才真的有意義。
至於隔離復現，很多偶發問題也都很難復現，可能是telemetry不夠可能是網路狀況奇怪可能是系統版本和某些依賴版本微妙，最後實際上大多數偶發問題都回變成碰運氣等復現，找到穩定復現就已經解決了問題的99%。

不如反過來說：軟體行業高強度的迭代正是源於這種「明確且即時」的預期，但這種預期直接造成了軟體行業的通病：因為一旦修復，修復可以很快被幾乎無成本部署，因此測試流程不全面不完整，開發時候主要考慮上線而不太考慮edge case；因為多一個if通常不會造成太多性能開銷也沒有部署成本，因此修復方式經常是patch特定狀況而不是停下來評估調整整個流程/架構。表面上迭代更快了，但是整個迭代的過程通常沒有讓軟體的品質變好，陷入一個惡性循環。大多數行業一旦東西交出去就沒有低成本的回頭路了，因此週期會比較長儘可能在週期中打磨成熟，週期結束後也會有一個相對細緻的複盤去檢討並尋求體系化的改良方法。這個過程好像不夠直觀反饋不夠即時，但是即時反饋更容易讓人不動腦子用膝跳反應處理問題，反而不是什麼好事。