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