作者ww410490 (致命伸卡球)
看板Soft_Job
標題[請益] PM要求實作未來會出問題的功能
時間Thu Jan 2 15:45:59 2020
年薪300的大神們 大家好
小弟想請教各位，有沒有遇過PM或老闆提出的需求，
是網站上線後，資料量變大才可能會出問題的那種，
這時候身為負責實現工程師，
(1)眼睛一閉，照做，到時候出問題再說
(2)試著跟PM溝通，解釋可能會遇到的問題，以及是否真的需要這個功能
(3)溝通無效，閃人為妙
請問單兵如何處置
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 140.109.161.23 (臺灣)
※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1577951161.A.3F1.html
1F：→ crossdunk: 看不懂 資料量變大才會出問題 那現在就會有問題啊 01/02 15:51
2F：→ ww410490: 是這樣的 資料量變大 導致loading過久 以及畫面變的雜亂 01/02 15:53
3F：推 gundam00: 先做啊 反正也不一定有機會資料量變大.... 01/02 15:53
4F：→ yuanruo: 不要over design 01/02 15:55
5F：→ ww410490: 好的 我也有反省 是不是我想太多 應該收錢就乖乖做事 01/02 15:56
6F：→ pttworld: 有問題也不是你扛，不過有問題要修改還是你 01/02 16:02
7F：→ benqm300: 等慢了再說，沒出來之前都是你的鍋。 01/02 16:05
8F：→ ww410490: 沒錯 我就是想到 出問題還是我來改 所以是不是要提醒PM 01/02 16:06
9F：推 v7q4: 做好error handling、寄信給PM cc主管 說這裡可能會有問題 01/02 16:15
10F：→ v7q4: PM死不改的話就不關你的事 反正你都已經先提醒了 01/02 16:15
11F：推 cheeseup: 你現在不做就現在被責難；現在先做之後才會被挖起來修 01/02 16:17
12F：→ cheeseup: 上一家公司就一堆前人留下來的洞，我是看ㄧ看之後也離開 01/02 16:19
13F：→ testPtt: loading過久就給進度條 畫面就重新排版而已 01/02 16:20
14F：→ ww410490: 這位大大說的也沒錯 但這個需求要做的事就多了很多 01/02 16:24
15F：推 nova06091: 直接開扁 01/02 16:26
16F：→ SimonAllen: 溝通 但不是不做而是討論大資料時那些部分要隱藏或大 01/02 16:45
17F：→ SimonAllen: 資料功能是否刪減 01/02 16:45
18F：→ ppppman: 就時間與成本問題 告知做或不做的影響 把你的專業和建議 01/02 17:06
19F：→ ppppman: 提出 大家來討論唄 01/02 17:07
20F：推 Aidan79225: 先做 之後資料真的變大再來改 01/02 17:09
21F：推 Ghamu: 拍桌大罵 不然請他們簽切結書 簽完祝公司無災無難 01/02 17:42
22F：→ Ghamu: 是說實務上還是先做再說吧 哈哈哈 謝謝你們公司為台灣創造 01/02 17:43
23F：→ Ghamu: 工作機會 01/02 17:43
24F：推 benedict76: 看起來不是會出問題只是實作過程麻煩懶得做XD 01/02 19:03
25F：推 pilor: lazy loading 01/02 19:37
26F：推 yyc1217: 看起來是想要一次性顯示所有資料？ 做成分頁應該不難 01/02 19:42
27F：推 sharek: 同意b大...看起來是沒有好方法或架構所以不想做？ 01/02 19:55
28F：推 b85040312: 有洞才有事做阿 01/02 20:07
29F：推 sxy67230: git commit 紀錄起來，押時間跟實現的功能敘述，然後紀 01/02 20:11
30F：→ sxy67230: 錄未來可能會發生什麼問題，真的發生被怪罪就直接調紀 01/02 20:12
31F：→ sxy67230: 錄啊 01/02 20:12
32F：噓 s06yji3: ... 01/02 20:15
33F：推 vi000246: 當然是先吵架 吵不贏開始做 做完又要改就能嗆回去了 01/02 20:17
34F：噓 final01: 那是工程師的問題，幹嘛推給PM 01/02 20:19
35F：推 benedict76: 基本上還沒做出來的東西然後跟pm說會有問題很難說服人 01/02 20:21
36F：→ benedict76: ，要是我是pm也是要看屍體。 01/02 20:21
37F：推 xlf: 提出問題 留下書面紀錄方便以後黑PM 01/02 20:30
38F：噓 s06yji3: 不應該是解決資料量變大會產生的問題嗎？ 01/02 20:33
39F：噓 Masakiad: 你應該要提供每一種solution 的人工、資料量跟效能的極 01/02 20:34
40F：→ Masakiad: 限給pm阿，難道這不是工程師該有的工作？決定要不要做 01/02 20:35
41F：→ Masakiad: 本來就是pm的工作，因為效能跟極限本來就是開出的spec 01/02 20:35
42F：→ Masakiad: 的一部分。 01/02 20:35
43F：→ onegoman: 標題跟內文是不是 ？？ 01/02 20:35
44F：推 chuegou: 不要怕留下技術債 還債不一定是你 01/02 20:36
45F：→ Masakiad: 怎麼會分不清楚什麼是自己的工作，什麼是同事的工作... 01/02 20:36
46F：→ airtsubasa: 以後也不是你維護，index可以好好開嗎 01/02 21:35
47F：推 zased: 能力不足的工程師才會設計出這種架構 01/02 22:22
48F：→ Obama19: 怎麼看都覺得是你的問題 01/02 22:30
49F：推 mercurycgt68: 債留子孫啦 現在能撈就撈能混就混 保險買好撐到18% 01/02 22:50
50F：→ mercurycgt68: 一切逮就撲 老人都在以身作則 你都沒用心學= = 01/02 22:51
51F：推 leo5916267: 有正常規劃就不會有這問題吧？ 01/02 23:08
52F：→ superpandal: 說過了 everything sucks 現在流行的做法就是疊疊樂 01/02 23:09
53F：→ superpandal: 堆疊保證 哪天倒了不知道 01/02 23:10
54F：→ superpandal: 我的路線沒錯歸沒錯 但肯定不受待見 hahaha 01/02 23:11
55F：→ superpandal: 語言、框架的坑都不少 01/02 23:12
56F：→ a47135: 趕時間或是不想做那麼多就預留解決的結構，等真的大到會出 01/02 23:25
57F：→ a47135: 問題再改，不過要提前說清楚就是了 01/02 23:25
58F：推 Muscovy: 其實你可以換個角度想, 反正這些都算工時... XD 01/03 00:25
59F：推 ckp4131025: 技術債是必然不是偶然 01/03 00:38
60F：→ ckp4131025: 你要做的是分析給PM 做取捨 01/03 00:39
61F：→ ckp4131025: 設計開發只有適合的沒有完美的 01/03 00:39
62F：→ ken1325: 技術債盡量留，後人才有事情做。 01/03 01:12
63F：→ superpandal: 不怕後面的人恨你是可以留技術債 不用寫的太好可以 01/03 01:49
64F：→ superpandal: 但留技術債是來搞人的 當元老有功 後面接手的人被搞 01/03 01:50
65F：→ superpandal: 評價肯定不會太好 老油條就是老油條 hahaha 01/03 01:51
66F：→ superpandal: 跨專業的接手例外 hahaha 01/03 01:58
67F：→ ww410490: 各位大大的建言 小弟銘記在心 目前決定先照做 以後的 01/03 07:44
68F：→ ww410490: 事以後再說 01/03 07:44
69F：推 internetms52: 資料太少，不好判斷，你要不要考慮多解釋一下情境 01/03 08:32
70F：噓 xevisu: 所以我才討厭半路出家外面上個半年課出來求職的，絕大多 01/03 08:38
71F：→ xevisu: 數都無法解決效能問題然候還敢開個5678萬 01/03 08:38
72F：→ superpandal: 我可以解決阿 那為何我仕途如此不順？ hahaha 一開始 01/03 09:01
73F：→ superpandal: 在台灣開這樣的確開高了 01/03 09:01
74F：→ superpandal: 有經歷就不一定了 01/03 09:02
75F：→ superpandal: 在台灣戰的大多數都是派系 同個語言下都是如此 01/03 09:09
76F：→ superpandal: 除了某些比較特殊的 01/03 09:09
77F：推 as885212: 開方案然後寄信或開會留記錄 才是合理的自保方式 01/03 09:24
78F：→ as885212: 不管技術債也不提醒的 就是放棄自己的尊嚴或專業 報復社 01/03 09:25
79F：→ as885212: 會而已 01/03 09:25
80F：→ superpandal: 分吧 分吧 分前人與後人 也分正逆觀點 hahaha 01/03 10:19
81F：推 Shawn5689: 先講 真要做出問題再嘴回去 負責決策的不是你 不需要煩 01/03 10:48
82F：→ Shawn5689: 惱那麼多 01/03 10:49
83F：噓 deray: timestamp在2037年會破表，我建議所有前端都應該禁止使用 01/03 12:07
84F：推 hidog: 能溝通就溝通 不能溝通就看什麼時候閃 01/03 12:20
85F：推 hidog: 風險問題可提可不提 看個人意願 01/03 12:23
86F：→ hidog: 如果上面堅持 就做 出包了閃人就沒你的事了 01/03 12:24
87F：→ pttworld: 樓樓上說的2038年是32位元吧，現在的64 01/03 14:28
88F：推 bubbleking: 需要告知他未來可能有問題 但要把決定權=責任留給他 01/03 15:08
89F：→ bubbleking: 不要去"說服"他 否則到時候有衍生問題他會推給你 01/03 15:08
90F：推 mago: 說真的有時候資料量會不會變大這件事是説不準的，重要的資 01/03 19:57
91F：→ mago: 料變大反而是好事，一開始over design不見得是對的，只要是 01/03 19:57
92F：→ allenxxx: 就是錢與時程的問題,有沒有遇過PM要你做:絕對沒問題的功 01/03 19:59
93F：→ allenxxx: 能?!也沒好到哪裡去 01/03 20:00
94F：→ steve1012: 資料量大就不行乍聽起來是engineer 的問題 01/04 04:55
95F：推 Masakiad: 樓上說這話聽起來像慣PM 01/04 16:19
96F：推 mago: 資料量大解法有很多種，有的甚至牽涉storage 更換， 寫拆開 01/04 17:11
97F：噓 iceonly: 多的時候會爆掉，那就多的時候再處理啊，不然你以為系統 01/05 02:39
98F：→ iceonly: 維護就是在debug?再說哪有啥資料量多就不能處理的事情， 01/05 02:39
99F：→ iceonly: 前端量多就virtual scrolling或paging或cache，查詢慢就s 01/05 02:39
100F：→ iceonly: olr或table設計好一點，資料無敵多就hadoop ecosystem弄 01/05 02:39
101F：→ iceonly: 下去。不過那也是之後再改的事，也沒有啥解決不了的問題 01/05 02:39
102F：推 justben: 看這Project賺的錢能不能抵銷出包的錢啊 XD 01/05 22:04
103F：推 oread168: 有文件的話可以寫一下已溝通過就好拉 01/06 20:22
104F：→ oread168: 怕到時候真的要改會被指指點點的話 01/06 20:23
105F：推 lturtsamuel: 資料量大就分頁啊== 你只是懶吧 01/06 22:46
106F：→ lturtsamuel: 你的資料難道會比臉書大? 01/06 22:46