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