Re: [閒聊] 各位工作有遇到甚麼很扯的事情嗎?
: 但以 PG 的角度而言，會很喜歡 log，巴不得程式裡頭發生的大小事
: 包含你家的蟑螂是不是生了一窩狗蛋這類的事，全部巨細靡遺全部塗牆記錄下來
: 當系統發生 bug 時，好讓他有足夠的訊息
: 可以分析系統在執行過程中的細節以利揪臭蟲
: 因為不同角色對 log 的需求不同，而且說真的
: 這部分很不容易在規劃之初就定義好，發生什麼事該 log，發生什麼事不該 log
: 甚至有很多案子在 SA 或 SD 階段，根本就是放掉 log 的問題不管
: 所以，該不該 log 這件事，在這種狀況下，就變成 PG 的自由心証
: 而且會傾向於 PG 自己的需求為主
: 當然，這個態勢不會持續發展下去，當這套系統開啟進行內部測試甚或推到客戶端時
: 過多的 log 必定會遭受眾人圍剿，這時就會被逼著開始砍 log
: 而且這個時候再砍 log 比較有道理，因為開發之初必定錯誤滿天飛
: 需要這些 log 來輔助，但一段時間之後，臭蟲抓得差不多了
: 這些 log 也漸漸失去當初的存在價值，最後該留下哪些 log 該砍掉哪些 log
: 大概是由眾人打架決定出來的
: 您所做的事，只不過就是這個砍 log 過程的其中一環而已
: 你覺得這個 log 很惱人，該模組的負責 PG 接受了你的需求，直接把它砍了
: 就只是這回事而已
: 若系統在開發之初就考慮到 log 處理機制，這個衝擊相對而言就小些
: 但我看過的眾多實例，有許多案子一開始沒把 log 當成一回事
: 等到進入開發期後半時，漸漸被 log 問題惹惱
: 這時要空降安插一套 log 處理機制的成本就高很多
我表達得不好 你可能誤解了
exception本身就表達了某些開發者無法估計的錯誤
要留不留看開發者是沒錯
當時的情境是那個exception表達的錯誤需要處理了
因為function的實作的邏輯有遺漏造成某些使用者行為無法完成
這個是已經從另一端得到反映要抓的bug
當初是要叫那個RD去檢查程式實做有沒有問題
結果得到的回應是一個鴕鳥心態眼不見為淨
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 111.249.182.90
推
09/12 22:36, , 1F
09/12 22:36, 1F
→
09/12 22:37, , 2F
09/12 22:37, 2F
→
09/12 22:38, , 3F
09/12 22:38, 3F
推
09/13 04:42, , 4F
09/13 04:42, 4F
→
09/13 04:43, , 5F
09/13 04:43, 5F
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 21 之 28 篇)：