[請益] 這樣的工作狀況是正常嗎?

看板Soft_Job作者 (宇宙學型男)時間6年前 (2019/02/14 13:37), 6年前編輯推噓22(22推 0噓 41→)
留言63則, 26人參與, 6年前最新討論串1/1
不好意思各位軟體業前輩來請益一個工作上的問題 我是去年才剛畢業的新人 原本並非本科系 在這之前也沒有相關工作經驗 陰錯陽差找了一個電商平台開發的軟體工作 最近因為工作越做越不愉快 但我並不想要在不確定是不是我的問題下就離職 (主要是上一份工作也是做了幾個月就離職 感覺頻繁換工作不好) 所以想上來請教一下 並非討拍 各式各樣建議好壞都歡迎 工作內容主要是各式各樣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://www.ptt.cc/bbs/Soft_Job/M.1550122678.A.768.html
推
02/14 13:40, 6年前 , 1F
摳濕摸了雞
02/14 13:40, 1F
推
02/14 13:43, 6年前 , 2F
如果只是自己的功能需求且其他人不介意，那可以在redis另
02/14 13:43, 2F
→
02/14 13:43, 6年前 , 3F
外拉一個新的鍵值處理！但如果這樣會動太多程式碼，那可
02/14 13:43, 3F
→
02/14 13:43, 6年前 , 4F
以用切換db，不過說真的也要看使用狀況才能決定
02/14 13:43, 4F
→
02/14 13:45, 6年前 , 5F
很多code到最後會越搞越糟就是因為沒有統一的規劃，都是
02/14 13:45, 5F
→
02/14 13:45, 6年前 , 6F
各做各的。久了就習慣了...這種狀況把自己手上的部分維護
02/14 13:45, 6F
→
02/14 13:45, 6年前 , 7F
好是最實在...
02/14 13:45, 7F
推
02/14 14:11, 6年前 , 8F
其實每一間公司做到一個程度之後 很多工作都是在解決大家
02/14 14:11, 8F
→
02/14 14:11, 6年前 , 9F
創造出來的bug...這很正常
02/14 14:11, 9F
推
02/14 14:19, 6年前 , 10F
看起來就是經驗不夠多 多工作幾年你就知道了
02/14 14:19, 10F
→
02/14 14:27, 6年前 , 11F
過幾年你也換公司了
02/14 14:27, 11F
推
02/14 14:33, 6年前 , 12F
常見但不覺得正常，經理的態度看起來也只是想要聽話的工
02/14 14:33, 12F
→
02/14 14:33, 6年前 , 13F
工程師，覺得這樣不優
02/14 14:33, 13F
推
02/14 14:34, 6年前 , 14F
Redis的意義就是不需要拿到Fresh Data的情況或是資料很
02/14 14:34, 14F
→
02/14 14:34, 6年前 , 15F
少更動的情況，如果你們一定要用到Fresh Data那就不應
02/14 14:34, 15F
→
02/14 14:34, 6年前 , 16F
該用Redis
02/14 14:34, 16F
推
02/14 14:36, 6年前 , 17F
不然就是每次request return cached data但是background
02/14 14:36, 17F
→
02/14 14:36, 6年前 , 18F
process query DB更新Redis
02/14 14:36, 18F
推
02/14 15:22, 6年前 , 19F
因為你的經理想省事, 不想做多餘的東西, 再來他沒有要
02/14 15:22, 19F
→
02/14 15:23, 6年前 , 20F
培養你的意思, 只是要一條聽命的__, 大概就是這樣, 可
02/14 15:23, 20F
→
02/14 15:23, 6年前 , 21F
以換公司了
02/14 15:23, 21F
→
02/14 15:52, 6年前 , 22F
有種即視感 我的前主管也是這種人 只想解決眼前問題
02/14 15:52, 22F
推
02/14 15:52, 6年前 , 23F
討厭類似文章 假問真狗幹公司 你就直接反推不就好
02/14 15:52, 23F
→
02/14 15:53, 6年前 , 24F
不會考慮程式的重用性跟可能造成的影響 提出建議又不理
02/14 15:53, 24F
→
02/14 15:54, 6年前 , 25F
最後的解決方式是離職 因為無法溝通的人很難共事...
02/14 15:54, 25F
→
02/14 15:55, 6年前 , 26F
現在這樣做只是在埋地雷 看誰衰小爆在誰手上
02/14 15:55, 26F
→
02/14 16:06, 6年前 , 27F
GET後再把資料放回去的方法不行，資料庫隨時在異動，你還
02/14 16:06, 27F
→
02/14 16:07, 6年前 , 28F
要證明你的程式沒有問題，也就是在開發階段的資料驗證，
02/14 16:07, 28F
→
02/14 16:08, 6年前 , 29F
如果你是另存表格還是多許多工作，存回原表格就是災難了
02/14 16:08, 29F
→
02/14 16:09, 6年前 , 30F
如果是另存新表，那就還好，只是多了許多新工作
02/14 16:09, 30F
→
02/14 16:11, 6年前 , 31F
工作最怕的一種人就是還未對全部系統都很了解，也不是系
02/14 16:11, 31F
推
02/14 16:11, 6年前 , 32F
建議換個老闆
02/14 16:11, 32F
→
02/14 16:11, 6年前 , 33F
統負責人，卻喜歡改前人的程式，你不知道這隻程式耦合了
02/14 16:11, 33F
→
02/14 16:12, 6年前 , 34F
了多少隻其他程式，一改不知要死多少。算你是負責人，明
02/14 16:12, 34F
→
02/14 16:14, 6年前 , 35F
天提離職怎辦，所以建議是先寫一支新的，用一陣子沒問題
02/14 16:14, 35F
→
02/14 16:14, 6年前 , 36F
後再宣告前一隻程式棄用。
02/14 16:14, 36F
→
02/14 16:16, 6年前 , 37F
看到 get 後還要回存資料我就無言了
02/14 16:16, 37F
→
02/14 16:20, 6年前 , 38F
除了這點你沒什麼問題，你的問題就是增加團隊的工作
02/14 16:20, 38F
→
02/14 16:21, 6年前 , 39F
量還有問題太多，你經理只要乖乖聽話的人
02/14 16:21, 39F
→
02/14 16:21, 6年前 , 40F
你這是好事，只是不適合團隊文化
02/14 16:21, 40F
推
02/14 16:30, 6年前 , 41F
看你喜不喜歡，整天兜圈子也是一樣的錢
02/14 16:30, 41F
推
02/14 17:37, 6年前 , 42F
應該是PUT的時候把快取刪掉，GET做更新可能race condition
02/14 17:37, 42F
推
02/14 18:50, 6年前 , 43F
我這邊也這樣 明明有經歷還被當白癡 問了被敷衍 不講出
02/14 18:50, 43F
→
02/14 18:50, 6年前 , 44F
來又被事後靠北 只想找條狗那幹嘛應徵新鮮人？
02/14 18:50, 44F
推
02/14 19:22, 6年前 , 45F
這主管很明顯不行吧...
02/14 19:22, 45F
→
02/14 21:46, 6年前 , 46F
這種狀況就是主管太弱導致 有些待久了就變成主管實在不可取
02/14 21:46, 46F
→
02/14 21:47, 6年前 , 47F
因為這種人常常是最走不出去的那個 而且可能很會挖坑
02/14 21:47, 47F
推
02/14 22:47, 6年前 , 48F
台灣很正常 這種公司主管很多
02/14 22:47, 48F
→
02/14 22:48, 6年前 , 49F
好心給意見 就是愛抱怨意見多
02/14 22:48, 49F
推
02/15 01:28, 6年前 , 50F
感覺是他有他的考量，只是不會溝通，這種人不適合當主管
02/15 01:28, 50F
推
02/15 02:29, 6年前 , 51F
大概就是因為非本科系 所以沒學過race condition吧...
02/15 02:29, 51F
→
02/15 02:29, 6年前 , 52F
這東西在CS應該是必修科目裡面都會教到 基本中的基本
02/15 02:29, 52F
→
02/15 02:30, 6年前 , 53F
不過既然是非本科 我覺得也就...沒啥好苛責的
02/15 02:30, 53F
推
02/15 08:21, 6年前 , 54F
race condition這種基本到不行的觀念居然一堆留換主
02/15 08:21, 54F
→
02/15 08:21, 6年前 , 55F
管
02/15 08:21, 55F
感謝各位前輩的意見 race condition這東西我以前在碰多線程有知道這類問題 我確實對我在做的東西不熟悉 也不確定是否有互斥鎖這類得去保護讀寫 那前輩意思應該是說這類基本問題主管/同事懶得回答 我本來就要自己有認知不能這樣做是吧?
推
02/15 09:25, 6年前 , 56F
不正常但很常見 唉
02/15 09:25, 56F
推
02/15 10:09, 6年前 , 57F
套句以前一位資深工程師的話 你們不產出一些bug 那老闆請這
02/15 10:09, 57F
→
02/15 10:10, 6年前 , 58F
麼多人衝三洨？所以 要感謝主管 感謝你身旁的工程師產出bug
02/15 10:10, 58F
→
02/15 10:10, 6年前 , 59F
來給你修 你才有工作做 才不會失業 懂？
02/15 10:10, 59F
※ 編輯: Cosmology (73.181.211.229), 02/15/2019 10:53:51
→
02/15 13:18, 6年前 , 60F
如果是拿 REDIS 來做 cache 分擔 DB 的 loading，就不是把它
02/15 13:18, 60F
→
02/15 13:19, 6年前 , 61F
當作db來用
02/15 13:19, 61F
推
02/16 00:43, 6年前 , 62F
因為你主管不強 弱者帶人就是這樣
02/16 00:43, 62F
推
02/17 11:00, 6年前 , 63F
年輕真好啊~~~
02/17 11:00, 63F
‣ 更多 Cosmology 的文章
文章代碼(AID): #1SPFwsTe (Soft_Job)