Re: [請益] PM要求實作未來會出問題的功能

看板Soft_Job作者 (睡魔)時間4年前 (2020/01/07 19:57), 編輯推噓0(003)
留言3則, 1人參與, 4年前最新討論串6/6 (看更多)
※ 引述《ripple0129 (perry tsai)》之銘言: : 通靈一下 : 問題是不是報表類啊 : 要全表或大量join大量計算的 : 資料少跑一下SQL就好 : 資料大跑到炸掉 : 會去想到資料大時會炸鍋 : 表示有經驗了啊 : 多的是新手沒想過這種問題 : 不過不要緊了 : 等慢到一定程度 : 就會開始跑daily的過去統計 : 到時重構就好 : 先求功能出來且正常 : 未來再處理效能 : 沒有足夠filter條件的SQL : 往往都是要重構的 : 別擔心遇到了處理就好 : 只要確定目前儲存的資料 : 未來有辦法做重構即可 : 如果現在設計的schema不符合未來重構 : 那就要換schema來儲存 以前遇過是客戶要的報表有可預料的效能問題(不要在數據庫對海量數據 進行recursive string concat). 但經理已經答應了客戶. 當時的做法是: 1) 要經理向客戶解釋情況, 最好說股客戶不要會出問題的部份. 不過這被經理否決了 2) 讓經理另外找人做, 別說我故意做差這功能. 結果代我做這報表的同事寫出來的東西, 即使在demo data量下也要跑十多分鐘 才能顯示. 後來我用我的方式重做, 也不過是把時間壓到一分鐘左右. 但留意這是在demo data 的環境下. 實際使用的話一年半載後不把那部份去後誰也別想救. 經理沒辦法下 也只能用我寫的去交差了. 當然, 一年半載後我已經離職了, 也沒看到後續如何. 重點是: 沒實作相應環境證明你說的情況, 上司不見得會聽進去. Clone一個環境, dummy fill一堆數據把量撐大, 讓上司實際看情況比較重要. 而更重要的是過程要loud, 要確定相關人物都知道你已經事先警告過了, 也花時間實業證明了, 這也要繼續的話, 日後出問題就和你沒關係了. -- -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 61.238.59.15 (香港) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1578398227.A.351.html

01/09 11:32, 4年前 , 1F
放心,"政治"就是討論問題出現了誰來背,尤其是推給離職
01/09 11:32, 1F

01/09 11:33, 4年前 , 2F
最方便
01/09 11:33, 2F

01/09 11:33, 4年前 , 3F
的那個來背最方便
01/09 11:33, 3F
文章代碼(AID): #1U578JDH (Soft_Job)
討論串 (同標題文章)
文章代碼(AID): #1U578JDH (Soft_Job)