作者:
ww410490 (致命伸卡球)
2020-01-02 15:45:59年薪300的大神們 大家好
小弟想請教各位，有沒有遇過PM或老闆提出的需求，
是網站上線後，資料量變大才可能會出問題的那種，
這時候身為負責實現工程師，
(1)眼睛一閉，照做，到時候出問題再說
(2)試著跟PM溝通，解釋可能會遇到的問題，以及是否真的需要這個功能
(3)溝通無效，閃人為妙
請問單兵如何處置
作者:
ww410490 (致命伸卡球)
2020-01-02 15:53:00是這樣的 資料量變大 導致loading過久 以及畫面變的雜亂
作者:
gundam00 (傻那駕駛中)
2020-01-02 15:53:00先做啊 反正也不一定有機會資料量變大....
作者:
yuanruo (罪を憎んで人を憎まず)
2020-01-02 15:55:00不要over design
作者:
ww410490 (致命伸卡球)
2020-01-02 15:56:00好的 我也有反省 是不是我想太多 應該收錢就乖乖做事
作者:
pttworld (批踢踢世界)
2020-01-02 16:02:00有問題也不是你扛，不過有問題要修改還是你
作者:
ww410490 (致命伸卡球)
2020-01-02 16:06:00沒錯 我就是想到 出問題還是我來改 所以是不是要提醒PM
作者:
v7q4 ((．)(．)乳劍雙修 -|＝＞)
2020-01-02 16:15:00做好error handling、寄信給PM cc主管 說這裡可能會有問題PM死不改的話就不關你的事 反正你都已經先提醒了
你現在不做就現在被責難；現在先做之後才會被挖起來修上一家公司就一堆前人留下來的洞，我是看ㄧ看之後也離開
作者:
testPtt (測試)
2020-01-02 16:20:00loading過久就給進度條 畫面就重新排版而已
作者:
ww410490 (致命伸卡球)
2020-01-02 16:24:00這位大大說的也沒錯 但這個需求要做的事就多了很多
溝通 但不是不做而是討論大資料時那些部分要隱藏或大資料功能是否刪減
作者: ppppman (4pman) 2020-01-02 17:06:00
就時間與成本問題 告知做或不做的影響 把你的專業和建議提出 大家來討論唄
作者:
Ghamu (貓丸)
2020-01-02 17:42:00拍桌大罵 不然請他們簽切結書 簽完祝公司無災無難是說實務上還是先做再說吧 哈哈哈 謝謝你們公司為台灣創造工作機會
作者:
pilor (Formosa)
2020-01-02 19:37:00lazy loading
作者:
yyc1217 (somo)
2020-01-02 19:42:00看起來是想要一次性顯示所有資料？ 做成分頁應該不難
作者:
sharek (...)
2020-01-02 19:55:00同意b大...看起來是沒有好方法或架構所以不想做？
作者:
sxy67230 (charlesgg)
2020-01-02 20:11:00git commit 紀錄起來，押時間跟實現的功能敘述，然後紀錄未來可能會發生什麼問題，真的發生被怪罪就直接調紀錄啊
作者: s06yji3 (阿南) 2020-01-02 20:15:00
...
當然是先吵架 吵不贏開始做 做完又要改就能嗆回去了
作者:
final01 (牛頓運動定律)
2020-01-02 20:19:00那是工程師的問題，幹嘛推給PM
基本上還沒做出來的東西然後跟pm說會有問題很難說服人，要是我是pm也是要看屍體。
作者:
xlf (Cote rocks!)
2020-01-02 20:30:00提出問題 留下書面紀錄方便以後黑PM
作者: s06yji3 (阿南) 2020-01-02 20:33:00
不應該是解決資料量變大會產生的問題嗎？
作者:
Masakiad (Masaki)
2020-01-02 20:34:00你應該要提供每一種solution 的人工、資料量跟效能的極限給pm阿，難道這不是工程師該有的工作？決定要不要做本來就是pm的工作，因為效能跟極限本來就是開出的spec的一部分。
作者:
chuegou (chuegou)
2020-01-02 20:36:00不要怕留下技術債 還債不一定是你
作者:
Masakiad (Masaki)
2020-01-02 20:36:00怎麼會分不清楚什麼是自己的工作，什麼是同事的工作...
作者:
zased (我只是上PTT查資料)
2020-01-02 22:22:00能力不足的工程師才會設計出這種架構
作者:
Obama19 (^_^)
2020-01-02 22:30:00怎麼看都覺得是你的問題
作者: mercurycgt68 (發芽的吉它手) 2020-01-02 22:50:00
債留子孫啦 現在能撈就撈能混就混 保險買好撐到18%一切逮就撲 老人都在以身作則 你都沒用心學= =
作者: superpandal 2020-01-02 23:09:00
說過了 everything sucks 現在流行的做法就是疊疊樂堆疊保證 哪天倒了不知道我的路線沒錯歸沒錯 但肯定不受待見 hahaha語言、框架的坑都不少
作者:
a47135 (金屬史萊姆)
2020-01-02 23:25:00趕時間或是不想做那麼多就預留解決的結構，等真的大到會出問題再改，不過要提前說清楚就是了
作者:
Muscovy (三分熟的鬧鐘)
2020-01-03 00:25:00其實你可以換個角度想, 反正這些都算工時... XD
技術債是必然不是偶然你要做的是分析給PM 做取捨設計開發只有適合的沒有完美的
作者:
ken1325 (優質水瓶男)
2020-01-03 01:12:00技術債盡量留，後人才有事情做。
作者: superpandal 2020-01-03 01:49:00
不怕後面的人恨你是可以留技術債 不用寫的太好可以但留技術債是來搞人的 當元老有功 後面接手的人被搞評價肯定不會太好 老油條就是老油條 hahaha跨專業的接手例外 hahaha
作者:
ww410490 (致命伸卡球)
2020-01-03 07:44:00各位大大的建言 小弟銘記在心 目前決定先照做 以後的事以後再說
作者: internetms52 (Oaide) 2020-01-03 08:32:00
資料太少，不好判斷，你要不要考慮多解釋一下情境
作者:
xevisu (大綠半糖少冰thx)
2020-01-03 08:38:00所以我才討厭半路出家外面上個半年課出來求職的，絕大多數都無法解決效能問題然候還敢開個5678萬
作者: superpandal 2020-01-03 09:01:00
我可以解決阿 那為何我仕途如此不順？ hahaha 一開始在台灣開這樣的確開高了有經歷就不一定了在台灣戰的大多數都是派系 同個語言下都是如此除了某些比較特殊的
作者: as885212 2020-01-03 09:24:00
開方案然後寄信或開會留記錄 才是合理的自保方式不管技術債也不提醒的 就是放棄自己的尊嚴或專業 報復社會而已
作者: superpandal 2020-01-03 10:19:00
分吧 分吧 分前人與後人 也分正逆觀點 hahaha
作者: Shawn5689 (Sion) 2020-01-03 10:48:00
先講 真要做出問題再嘴回去 負責決策的不是你 不需要煩惱那麼多
作者:
deray (Deray)
2020-01-03 12:07:00timestamp在2037年會破表，我建議所有前端都應該禁止使用
作者: hidog (.....) 2020-01-03 12:20:00
能溝通就溝通 不能溝通就看什麼時候閃風險問題可提可不提 看個人意願如果上面堅持 就做 出包了閃人就沒你的事了
作者:
pttworld (批踢踢世界)
2020-01-03 14:28:00樓樓上說的2038年是32位元吧，現在的64
需要告知他未來可能有問題 但要把決定權=責任留給他不要去"說服"他 否則到時候有衍生問題他會推給你
作者:
mago (mago)
2020-01-03 19:57:00說真的有時候資料量會不會變大這件事是説不準的，重要的資料變大反而是好事，一開始over design不見得是對的，只要是
作者:
allenxxx (fufuxxx)
2020-01-03 19:59:00就是錢與時程的問題,有沒有遇過PM要你做:絕對沒問題的功能?!也沒好到哪裡去
作者:
Masakiad (Masaki)
2020-01-04 16:19:00樓上說這話聽起來像慣PM
作者:
mago (mago)
2020-01-04 17:11:00資料量大解法有很多種，有的甚至牽涉storage 更換， 寫拆開
作者:
iceonly (只有冰)
2020-01-05 02:39:00多的時候會爆掉，那就多的時候再處理啊，不然你以為系統維護就是在debug?再說哪有啥資料量多就不能處理的事情，前端量多就virtual scrolling或paging或cache，查詢慢就solr或table設計好一點，資料無敵多就hadoop ecosystem弄下去。不過那也是之後再改的事，也沒有啥解決不了的問題
作者:
justben (BEN)
2020-01-05 22:04:00看這Project賺的錢能不能抵銷出包的錢啊 XD
作者:
oread168 (大地的精éˆR)
2020-01-06 20:22:00有文件的話可以寫一下已溝通過就好拉怕到時候真的要改會被指指點點的話
資料量大就分頁啊== 你只是懶吧你的資料難道會比臉書大?