作者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/cn.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