楼主:
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有文件的话可以写一下已沟通过就好拉怕到时候真的要改会被指指点点的话
资料量大就分页啊== 你只是懒吧你的资料难道会比脸书大?