作者Cosmology (宇宙学型男)
看板Soft_Job
标题[请益] 这样的工作状况是正常吗?
时间Thu Feb 14 13:37:56 2019
不好意思各位软体业前辈来请益一个工作上的问题
我是去年才刚毕业的新人
原本并非本科系 在这之前也没有相关工作经验
阴错阳差找了一个电商平台开发的软体工作
最近因为工作越做越不愉快 但我并不想要在不确定是不是我的问题下就离职
(主要是上一份工作也是做了几个月就离职 感觉频繁换工作不好)
所以想上来请教一下 并非讨拍 各式各样建议好坏都欢迎
工作内容主要是各式各样RESTful API的开发
然後要把这些资料存到SQL之类的
目前没什麽大问题 我自己google可以找到大部分答案
但是例如商业模式这块我不是很了解
如果我不知道这些商业模式 我怎麽去写东西出来?
常常在那边自己看很久却不知道这些东西的意义到底是甚麽
例如某间仓库的编号是99 这间仓库可能就要做特别的库存处理
所以可能会前面的人会hard code一些东西
或是当碰到编号99的时候 用户可以订阅的数量就要做调整等等
再来技术上最近遇到的问题
例如我们有用redis这种东西(好像是可以加快存取速度 我自己上网查的)
我有一个GET是可以看库存数量的 然後有个PUT可以更新库存数量
GET的API给一个组员改写过 所以用Postman显示出来的结果是跟存在SQL的是不一样的
(组上说这叫动态计算?)
可是这会有个问题其他的API却没办法从SQL读到正确的结果 所以我要去修这个问题
我想法是即使是GET以後 应该要把算出来的结果再存回去SQL让大家都能同步
但经理并不是很喜欢这样的作法 而是要我改其他有用到这个资料的API
让他们每个都可以去动态计算这个结果
我心里真的不懂为什麽要去改N个东西而不是去改一个东西就好
或是我有要试着更新redis的cache 让其他API可以抓到比较即时的资料
但他却觉得他不想管这个 他只要我去改他想看到的这块东西
我说那这样QA测的时候 他们可能会测到没有更新过的cache
这样他们不会觉得我们哪里弄错吗?
我每次问主管这类问题 他给我的感觉是他并不太想回答 不然就是显得好像很不耐烦
大概的回话就是
我: 为什麽遇到仓库编号是99的时候 他们要做特别的处理 他们有特别的地方吗?
那我在什麽情况下要做类似这样的处理 让我方便之後遇到类似情况我可以直接改?
经理: 以後遇到再说
我提问是否要改OOXX(并没有commit任何东西或是到peer review阶段)
经理: 我说改这边就好
我: 可是我们只要OOXX 或是我们只要%$%^# 应该就可以...
经理: 我说了就这样改就好 为什麽这样改对你来说这麽困难呢
我: 不是困难 可是我们这样改 不是XXYY也会受影响吗?
经理: 我说了就改这边了 你干嘛要一直质疑(挑战)我之类的话
(照经理改完後我还是不确定XXYY到底有没有受影响)
(有时候可能没事 或是几天後知道要修的东西就是XXYY)
这里我强调我都还是有好好照他的把工作完成
我不是不愿意照经理的意思这样做
但是每次QA再把任务丢回来 他可能就会开会检讨东西为什麽又会丢回来
可是我心里都OS说这些问题不是我们应该早就要注意吗?
例如更新cache这边 我自己写完测试都觉得超奇怪了 怎麽可能还要送去QA或产品上线?
当然拿人钱财替人消灾 就做经理交代的就好
这样我完全没问题
公司给我感觉是大家创造了很多BUGS 然後大家的工作就是解大家创造出来的这些东西
然後大家都在玩叠叠乐?的感觉
只要东西修好来 东西不会倒就好 遇到下个问题再说 绝对不允许改其它地方
这点我同意 毕竟我也不是完全了解这系统 我也不敢乱改
但是难道想讨论一下为什麽能(或不能)这样弄会让组员/经理很烦是吗?
还是说很多东西说了也没意义? 以後就知道为什麽了 所以不要一直问?
或是我刚毕业都对工作存有太多不切实际的想法?
反正上班照经理的话做就好 按时把工作完成
有问题遇到再说 剩下的不要问东问西
是觉得这样也不是不行 只是希望我的工作不是在解大家创造出来的Bug
然後可以有系统一点的去处理事情这样
我有看过本版28780带新人感想的每一篇文
觉得自己应该没有什麽大问题 所以才上来请教 谢谢
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 73.181.211.229
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1550122678.A.768.html
1F：推 pttnowash: 抠湿摸了鸡 02/14 13:40
2F：推 s890510: 如果只是自己的功能需求且其他人不介意，那可以在redis另 02/14 13:43
3F：→ s890510: 外拉一个新的键值处理！但如果这样会动太多程式码，那可 02/14 13:43
4F：→ s890510: 以用切换db，不过说真的也要看使用状况才能决定 02/14 13:43
5F：→ s890510: 很多code到最後会越搞越糟就是因为没有统一的规划，都是 02/14 13:45
6F：→ s890510: 各做各的。久了就习惯了...这种状况把自己手上的部分维护 02/14 13:45
7F：→ s890510: 好是最实在... 02/14 13:45
8F：推 kurtsgm: 其实每一间公司做到一个程度之後 很多工作都是在解决大家 02/14 14:11
9F：→ kurtsgm: 创造出来的bug...这很正常 02/14 14:11
10F：推 crossdunk: 看起来就是经验不够多 多工作几年你就知道了 02/14 14:19
11F：→ pttworld: 过几年你也换公司了 02/14 14:27
12F：推 t64141: 常见但不觉得正常，经理的态度看起来也只是想要听话的工 02/14 14:33
13F：→ t64141: 工程师，觉得这样不优 02/14 14:33
14F：推 lemon651: Redis的意义就是不需要拿到Fresh Data的情况或是资料很 02/14 14:34
15F：→ lemon651: 少更动的情况，如果你们一定要用到Fresh Data那就不应 02/14 14:34
16F：→ lemon651: 该用Redis 02/14 14:34
17F：推 lemon651: 不然就是每次request return cached data但是background 02/14 14:36
18F：→ lemon651: process query DB更新Redis 02/14 14:36
19F：推 shooter555: 因为你的经理想省事, 不想做多余的东西, 再来他没有要 02/14 15:22
20F：→ shooter555: 培养你的意思, 只是要一条听命的__, 大概就是这样, 可 02/14 15:23
21F：→ shooter555: 以换公司了 02/14 15:23
22F：→ vi000246: 有种即视感 我的前主管也是这种人 只想解决眼前问题 02/14 15:52
23F：推 s001582000: 讨厌类似文章 假问真狗干公司 你就直接反推不就好 02/14 15:52
24F：→ vi000246: 不会考虑程式的重用性跟可能造成的影响 提出建议又不理 02/14 15:53
25F：→ vi000246: 最後的解决方式是离职 因为无法沟通的人很难共事... 02/14 15:54
26F：→ vi000246: 现在这样做只是在埋地雷 看谁衰小爆在谁手上 02/14 15:55
27F：→ AvatarH: GET後再把资料放回去的方法不行，资料库随时在异动，你还 02/14 16:06
28F：→ AvatarH: 要证明你的程式没有问题，也就是在开发阶段的资料验证， 02/14 16:07
29F：→ AvatarH: 如果你是另存表格还是多许多工作，存回原表格就是灾难了 02/14 16:08
30F：→ AvatarH: 如果是另存新表，那就还好，只是多了许多新工作 02/14 16:09
31F：→ AvatarH: 工作最怕的一种人就是还未对全部系统都很了解，也不是系 02/14 16:11
32F：推 Vick753: 建议换个老板 02/14 16:11
33F：→ AvatarH: 统负责人，却喜欢改前人的程式，你不知道这只程式耦合了 02/14 16:11
34F：→ AvatarH: 了多少只其他程式，一改不知要死多少。算你是负责人，明 02/14 16:12
35F：→ AvatarH: 天提离职怎办，所以建议是先写一支新的，用一阵子没问题 02/14 16:14
36F：→ AvatarH: 後再宣告前一只程式弃用。 02/14 16:14
37F：→ diabloevagto: 看到 get 後还要回存资料我就无言了 02/14 16:16
38F：→ diabloevagto: 除了这点你没什麽问题，你的问题就是增加团队的工作 02/14 16:20
39F：→ diabloevagto: 量还有问题太多，你经理只要乖乖听话的人 02/14 16:21
40F：→ diabloevagto: 你这是好事，只是不适合团队文化 02/14 16:21
41F：推 ayanami00: 看你喜不喜欢，整天兜圈子也是一样的钱 02/14 16:30
42F：推 seedli: 应该是PUT的时候把快取删掉，GET做更新可能race condition 02/14 17:37
43F：推 azureroki: 我这边也这样 明明有经历还被当白痴 问了被敷衍 不讲出 02/14 18:50
44F：→ azureroki: 来又被事後靠北 只想找条狗那干嘛应徵新鲜人？ 02/14 18:50
45F：推 abccbaandy: 这主管很明显不行吧... 02/14 19:22
46F：→ y3k: 这种状况就是主管太弱导致 有些待久了就变成主管实在不可取 02/14 21:46
47F：→ y3k: 因为这种人常常是最走不出去的那个 而且可能很会挖坑 02/14 21:47
48F：推 googoo1102: 台湾很正常 这种公司主管很多 02/14 22:47
49F：→ googoo1102: 好心给意见 就是爱抱怨意见多 02/14 22:48
50F：推 rahit: 感觉是他有他的考量，只是不会沟通，这种人不适合当主管 02/15 01:28
51F：推 kurtsgm: 大概就是因为非本科系 所以没学过race condition吧... 02/15 02:29
52F：→ kurtsgm: 这东西在CS应该是必修科目里面都会教到 基本中的基本 02/15 02:29
53F：→ kurtsgm: 不过既然是非本科 我觉得也就...没啥好苛责的 02/15 02:30
54F：推 mystery7631: race condition这种基本到不行的观念居然一堆留换主 02/15 08:21
55F：→ mystery7631: 管 02/15 08:21
感谢各位前辈的意见 race condition这东西我以前在碰多线程有知道这类问题
我确实对我在做的东西不熟悉 也不确定是否有互斥锁这类得去保护读写
那前辈意思应该是说这类基本问题主管/同事懒得回答
我本来就要自己有认知不能这样做是吧?
56F：推 wuliou: 不正常但很常见 唉 02/15 09:25
57F：推 Argos: 套句以前一位资深工程师的话 你们不产出一些bug 那老板请这 02/15 10:09
58F：→ Argos: 麽多人冲三洨？所以 要感谢主管 感谢你身旁的工程师产出bug 02/15 10:10
59F：→ Argos: 来给你修 你才有工作做 才不会失业 懂？ 02/15 10:10
※ 编辑: Cosmology (73.181.211.229), 02/15/2019 10:53:51
60F：→ hstt: 如果是拿 REDIS 来做 cache 分担 DB 的 loading，就不是把它 02/15 13:18
61F：→ hstt: 当作db来用 02/15 13:19
62F：推 andy29433: 因为你主管不强 弱者带人就是这样 02/16 00:43
63F：推 g4ru04: 年轻真好啊~~~ 02/17 11:00