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

看板Soft_Job作者 (致命伸卡球)時間4年前 (2020/01/02 15:46), 編輯推噓26(33推 7噓 66→)
留言106則, 51人參與, 4年前最新討論串1/6 (看更多)
年薪300的大神們 大家好 小弟想請教各位，有沒有遇過PM或老闆提出的需求， 是網站上線後，資料量變大才可能會出問題的那種， 這時候身為負責實現工程師， (1)眼睛一閉，照做，到時候出問題再說 (2)試著跟PM溝通，解釋可能會遇到的問題，以及是否真的需要這個功能 (3)溝通無效，閃人為妙 請問單兵如何處置 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 140.109.161.23 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1577951161.A.3F1.html
→
01/02 15:51, 4年前 , 1F
看不懂 資料量變大才會出問題 那現在就會有問題啊
01/02 15:51, 1F
→
01/02 15:53, 4年前 , 2F
是這樣的 資料量變大 導致loading過久 以及畫面變的雜亂
01/02 15:53, 2F
推
01/02 15:53, 4年前 , 3F
先做啊 反正也不一定有機會資料量變大....
01/02 15:53, 3F
→
01/02 15:55, 4年前 , 4F
不要over design
01/02 15:55, 4F
→
01/02 15:56, 4年前 , 5F
好的 我也有反省 是不是我想太多 應該收錢就乖乖做事
01/02 15:56, 5F
→
01/02 16:02, 4年前 , 6F
有問題也不是你扛，不過有問題要修改還是你
01/02 16:02, 6F
→
01/02 16:05, 4年前 , 7F
等慢了再說，沒出來之前都是你的鍋。
01/02 16:05, 7F
→
01/02 16:06, 4年前 , 8F
沒錯 我就是想到 出問題還是我來改 所以是不是要提醒PM
01/02 16:06, 8F
推
01/02 16:15, 4年前 , 9F
做好error handling、寄信給PM cc主管 說這裡可能會有問題
01/02 16:15, 9F
→
01/02 16:15, 4年前 , 10F
PM死不改的話就不關你的事 反正你都已經先提醒了
01/02 16:15, 10F
推
01/02 16:17, 4年前 , 11F
你現在不做就現在被責難；現在先做之後才會被挖起來修
01/02 16:17, 11F
→
01/02 16:19, 4年前 , 12F
上一家公司就一堆前人留下來的洞，我是看ㄧ看之後也離開
01/02 16:19, 12F
→
01/02 16:20, 4年前 , 13F
loading過久就給進度條 畫面就重新排版而已
01/02 16:20, 13F
→
01/02 16:24, 4年前 , 14F
這位大大說的也沒錯 但這個需求要做的事就多了很多
01/02 16:24, 14F
推
01/02 16:26, 4年前 , 15F
直接開扁
01/02 16:26, 15F
→
01/02 16:45, 4年前 , 16F
溝通 但不是不做而是討論大資料時那些部分要隱藏或大
01/02 16:45, 16F
→
01/02 16:45, 4年前 , 17F
資料功能是否刪減
01/02 16:45, 17F
→
01/02 17:06, 4年前 , 18F
就時間與成本問題 告知做或不做的影響 把你的專業和建議
01/02 17:06, 18F
→
01/02 17:07, 4年前 , 19F
提出 大家來討論唄
01/02 17:07, 19F
推
01/02 17:09, 4年前 , 20F
先做 之後資料真的變大再來改
01/02 17:09, 20F
推
01/02 17:42, 4年前 , 21F
拍桌大罵 不然請他們簽切結書 簽完祝公司無災無難
01/02 17:42, 21F
→
01/02 17:43, 4年前 , 22F
是說實務上還是先做再說吧 哈哈哈 謝謝你們公司為台灣創造
01/02 17:43, 22F
→
01/02 17:43, 4年前 , 23F
工作機會
01/02 17:43, 23F
推
01/02 19:03, 4年前 , 24F
看起來不是會出問題只是實作過程麻煩懶得做XD
01/02 19:03, 24F
推
01/02 19:37, 4年前 , 25F
lazy loading
01/02 19:37, 25F
推
01/02 19:42, 4年前 , 26F
看起來是想要一次性顯示所有資料？ 做成分頁應該不難
01/02 19:42, 26F
推
01/02 19:55, 4年前 , 27F
同意b大...看起來是沒有好方法或架構所以不想做？
01/02 19:55, 27F
推
01/02 20:07, 4年前 , 28F
有洞才有事做阿
01/02 20:07, 28F
推
01/02 20:11, 4年前 , 29F
git commit 紀錄起來，押時間跟實現的功能敘述，然後紀
01/02 20:11, 29F
→
01/02 20:12, 4年前 , 30F
錄未來可能會發生什麼問題，真的發生被怪罪就直接調紀
01/02 20:12, 30F
→
01/02 20:12, 4年前 , 31F
錄啊
01/02 20:12, 31F
噓
01/02 20:15, 4年前 , 32F
...
01/02 20:15, 32F
推
01/02 20:17, 4年前 , 33F
當然是先吵架 吵不贏開始做 做完又要改就能嗆回去了
01/02 20:17, 33F
噓
01/02 20:19, 4年前 , 34F
那是工程師的問題，幹嘛推給PM
01/02 20:19, 34F
推
01/02 20:21, 4年前 , 35F
基本上還沒做出來的東西然後跟pm說會有問題很難說服人
01/02 20:21, 35F
→
01/02 20:21, 4年前 , 36F
，要是我是pm也是要看屍體。
01/02 20:21, 36F
推
01/02 20:30, 4年前 , 37F
提出問題 留下書面紀錄方便以後黑PM
01/02 20:30, 37F
噓
01/02 20:33, 4年前 , 38F
不應該是解決資料量變大會產生的問題嗎？
01/02 20:33, 38F
噓
01/02 20:34, 4年前 , 39F
你應該要提供每一種solution 的人工、資料量跟效能的極
01/02 20:34, 39F
還有 27 則推文
→
01/03 07:44, 4年前 , 67F
各位大大的建言 小弟銘記在心 目前決定先照做 以後的
01/03 07:44, 67F
→
01/03 07:44, 4年前 , 68F
事以後再說
01/03 07:44, 68F
推
01/03 08:32, 4年前 , 69F
資料太少，不好判斷，你要不要考慮多解釋一下情境
01/03 08:32, 69F
噓
01/03 08:38, 4年前 , 70F
所以我才討厭半路出家外面上個半年課出來求職的，絕大多
01/03 08:38, 70F
→
01/03 08:38, 4年前 , 71F
數都無法解決效能問題然候還敢開個5678萬
01/03 08:38, 71F
→
01/03 09:01, 4年前 , 72F
我可以解決阿 那為何我仕途如此不順？ hahaha 一開始
01/03 09:01, 72F
→
01/03 09:01, 4年前 , 73F
在台灣開這樣的確開高了
01/03 09:01, 73F
→
01/03 09:02, 4年前 , 74F
有經歷就不一定了
01/03 09:02, 74F
→
01/03 09:09, 4年前 , 75F
在台灣戰的大多數都是派系 同個語言下都是如此
01/03 09:09, 75F
→
01/03 09:09, 4年前 , 76F
除了某些比較特殊的
01/03 09:09, 76F
推
01/03 09:24, 4年前 , 77F
開方案然後寄信或開會留記錄 才是合理的自保方式
01/03 09:24, 77F
→
01/03 09:25, 4年前 , 78F
不管技術債也不提醒的 就是放棄自己的尊嚴或專業 報復社
01/03 09:25, 78F
→
01/03 09:25, 4年前 , 79F
會而已
01/03 09:25, 79F
→
01/03 10:19, 4年前 , 80F
分吧 分吧 分前人與後人 也分正逆觀點 hahaha
01/03 10:19, 80F
推
01/03 10:48, 4年前 , 81F
先講 真要做出問題再嘴回去 負責決策的不是你 不需要煩
01/03 10:48, 81F
→
01/03 10:49, 4年前 , 82F
惱那麼多
01/03 10:49, 82F
噓
01/03 12:07, 4年前 , 83F
timestamp在2037年會破表，我建議所有前端都應該禁止使用
01/03 12:07, 83F
推
01/03 12:20, 4年前 , 84F
能溝通就溝通 不能溝通就看什麼時候閃
01/03 12:20, 84F
推
01/03 12:23, 4年前 , 85F
風險問題可提可不提 看個人意願
01/03 12:23, 85F
→
01/03 12:24, 4年前 , 86F
如果上面堅持 就做 出包了閃人就沒你的事了
01/03 12:24, 86F
→
01/03 14:28, 4年前 , 87F
樓樓上說的2038年是32位元吧，現在的64
01/03 14:28, 87F
推
01/03 15:08, 4年前 , 88F
需要告知他未來可能有問題 但要把決定權=責任留給他
01/03 15:08, 88F
→
01/03 15:08, 4年前 , 89F
不要去"說服"他 否則到時候有衍生問題他會推給你
01/03 15:08, 89F
推
01/03 19:57, 4年前 , 90F
說真的有時候資料量會不會變大這件事是説不準的，重要的資
01/03 19:57, 90F
→
01/03 19:57, 4年前 , 91F
料變大反而是好事，一開始over design不見得是對的，只要是
01/03 19:57, 91F
→
01/03 19:59, 4年前 , 92F
就是錢與時程的問題,有沒有遇過PM要你做:絕對沒問題的功
01/03 19:59, 92F
→
01/03 20:00, 4年前 , 93F
能?!也沒好到哪裡去
01/03 20:00, 93F
→
01/04 04:55, 4年前 , 94F
資料量大就不行乍聽起來是engineer 的問題
01/04 04:55, 94F
推
01/04 16:19, 4年前 , 95F
樓上說這話聽起來像慣PM
01/04 16:19, 95F
推
01/04 17:11, 4年前 , 96F
資料量大解法有很多種，有的甚至牽涉storage 更換， 寫拆開
01/04 17:11, 96F
噓
01/05 02:39, 4年前 , 97F
多的時候會爆掉，那就多的時候再處理啊，不然你以為系統
01/05 02:39, 97F
→
01/05 02:39, 4年前 , 98F
維護就是在debug?再說哪有啥資料量多就不能處理的事情，
01/05 02:39, 98F
→
01/05 02:39, 4年前 , 99F
前端量多就virtual scrolling或paging或cache，查詢慢就s
01/05 02:39, 99F
→
01/05 02:39, 4年前 , 100F
olr或table設計好一點，資料無敵多就hadoop ecosystem弄
01/05 02:39, 100F
→
01/05 02:39, 4年前 , 101F
下去。不過那也是之後再改的事，也沒有啥解決不了的問題
01/05 02:39, 101F
推
01/05 22:04, 4年前 , 102F
看這Project賺的錢能不能抵銷出包的錢啊 XD
01/05 22:04, 102F
推
01/06 20:22, 4年前 , 103F
有文件的話可以寫一下已溝通過就好拉
01/06 20:22, 103F
→
01/06 20:23, 4年前 , 104F
怕到時候真的要改會被指指點點的話
01/06 20:23, 104F
推
01/06 22:46, 4年前 , 105F
資料量大就分頁啊== 你只是懶吧
01/06 22:46, 105F
→
01/06 22:46, 4年前 , 106F
你的資料難道會比臉書大?
01/06 22:46, 106F
‣ 更多 ww410490 的文章
文章代碼(AID): #1U3P-vFn (Soft_Job)
討論串 (同標題文章)
以下文章回應了本文 (最舊先)：
完整討論串 (本文為第 1 之 6 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共6篇)
‣ 更多 ww410490 的文章
文章代碼(AID): #1U3P-vFn (Soft_Job)