最近案子快收尾在收斂bug
身為救援大隊長的老人我被指派到維護一個很老的API
老API的設計已經無法滿足擴充需求
新的擴充功能造成BUG
於是我花了大量時間甚至debug到天亮甚至請無薪假
新的API經過我反覆測試各種case都完美無缺
但是code review卻被質疑:
1. 是不是沒找到root cause
2. 幹嘛改動如此大? 只不過新加一點點功能幹嘛改架構?
心中五味雜陳...
好歹我也是coding master，我說該重構了就是該開始還技術債了
更上頭還是希望用最鴕鳥的方法繼續用舊架構一堆workaound當作root cause
是該離職了嗎? QwQ

維護的是你，不是他們。所以他們只想安全牌。不會管技術債換人厚，會多難接。一堆不知所以然的code。

code直接丟github開源全世界共享 然後特休全壓放老人自己去解root cause啊 這還要教？

錢給到位嗎 有成長空間嗎 都沒有就走人XD

公司:能動最重要，你有看過醫院那些名醫看小病就要開刀的嗎??XD特別是老人家，沒事就別亂開刀了萬一有糾紛理由一大堆不用當真

一堆公司都這樣 能動就好改這麼大做什麼 出問題你扛得住嗎

可以重構啊，你不會等案子結束再重構？

問題是你重構完 上頭買單?其他人接手會用會改？要多少時間熟悉你的code以上這只針對公司老人

可能只是不想要欠這種人情 也不想花錢請你重構 所以才這樣回

很久以前我也跟你一樣 後來看開了 拿多少錢做多少事除非上頭有交代不然這些重構還是新東西自己改改玩玩 不會放檯面上，頂多找面試拿來講講

那你就新舊都兼容啊 你的 pr 應該只有增加的行數沒有砍舊邏輯

專案要先把責任切開 大雜燴下 對專案的風險感就會混雜

程式已經亂到flag亂跳...可讀性0..

老人還被質疑喔...

是說派你去救火的人 又不滿意你的方案嗎==

他錢有給到你捨不得離職嗎 XD

上面還有更老的的人啊...

M有要你重構？如果沒有，你要重構，不應該先跟他討論?y說到底 IC 也只是 M 的資源，資源怎麼用是M的職責和權力事情發生後，建議可以去找M聊，解決問題 而不是想著離職

coding master是什麼鬼

如果你不確定這個決定會不會被靠腰，你可以找比你懂公司狀況的人或者主管討論，而不是自己做決定

那你就真擴充而不是順手重構 看行數最快

除非你是決策者否則要重構要看大家意見 這不是技術好不好

我有遇到遇到跟你一樣的狀況。明明團隊 wiki 有前人留下 guide line，寫童子軍原則：順手改掉周圍的爛code。結果 review 後被要求全部 revert 回去，因為 reviewer 覺得跟需求無關的變動太多，造成他的負擔。

順手要能改前提是有測試吧 不然應該是先補測試

這是重寫，不是重構

推一樓~都到master了,講的話還沒人信喔@@...

原始任務是解bug。要開新任務（重構），請先和派任務的人溝通。

上線前：亂一點沒關係先把東西趕出來我們再回頭重構/ 上線後：好好的你改它幹嘛？

你的好意可能是他人的災難 有些東西還是要討論一下再決定 不要做無效工作 忙的要死得了一個非預期的結果 自己很挫折無意義

讓你認清現實這間公司是來甩鍋的不是來貢獻的

我只覺得coding是你 testing也是你 是一件很奇怪的事情

這件事的問題是 事前溝通。沒說服就做 浪費彼此時間

你這也不是一天的工作吧 中間沒人反應？？

該離職了

重構前稍微跟別人提一下吧…

看過一些溝通方面的書籍，原PO上層還有決策者的話，要先說服或告知決策者，讓他們心裡有預期，看起來你做的和決策者的預期有所出入，才會被打槍

沒先溝通好的問題

原始任務是除錯對嗎？ 這樣的話，設計爛做不了就回報吧不然把除錯做成更花資源且異動更大的重構人家也不領情說重構可能還客氣了。如果直接變成新API，那算是改寫或重新設計……這樣如果人家不收其實也不令人非常意外

原本維護API可以很多人維護，你這一改，只剩你知道了。這樣真的是只有自己對嗎？ 不一定喔。你有權限負責整個專案，或整個部門的考績嗎？ 沒權限的話，這樣改。即即使技術沒問題，千萬不要認為是對的。到任何公司都可能得罪人。

取暖喔 自以為是的重構

傻子才自己在那邊重構

通常這種情況代表沒實力的怕事裝逼仔在上位，會讓這種逼洨上去的部門主管方向感也不是很好，如果薪資不是特別好應該可以閃人了不過還是要看規模，如果是一千行以內我都覺得還好。超過一千行就真的要思考了不用屌樓上一堆嘴重構的嫩逼，techjob都是搞硬體的廢材，而且科技業95%都是冗員廢材，所以留言有95%怕事廢材也合理幹原來是softjob，那更慘了，大部分都是台灣系新創小規模公司廢材，薪水大概半導體業1/2，更不能參考

沒人嘴重構好嗎。我們嘴的是：重構前，不先溝通。

有共識、排進去時程的重構才比較不會出現這個問題。自己重構通常都是小規模、PR review 容易看懂的規模

怎麼有人留言看一看自己破防XDD

你如果這麼資深了 東西又有做出來 怎麼還會有人在程式碼層面質疑你？感覺很怪 是不是有牙膏沒擠回到這兩個問題都很合理 而且都不難回答吧 你有沒有找到根因？修正那個根因需不需要這麼大的改動？一百字以內就應該回答清楚的問題 答不出來先去訓練表達能力==

你上一位接手可能也是這樣想，然後每新來一位每一位都在重構，每次專案的程式碼都不一樣

問題是review前為啥不暴露一下你要做這件事大家討論一下有沒有價值你就自己單幹但是上面覺得沒用那就是沒用啊

老問題了 你想扛上面不想扛我也遇過就是做ppt跟上面報告一輪

看到debug到天亮就想笑鬼島慣老闆這麼多就是你這種人養的

重構要有計畫跟目標，而且定期，不是遇到問題重構你這樣搞下去有問題怎麼知道是新問題還是原問題跟質疑其實也沒啥關係，就是其他人聽了會覺得很危險

沒上頭指示幹嘛重構，不夠忙吧

如果是我，就先做ppt、拉會議安排code review，最終更上面說要怎麼做就怎麼做，反正我把決策責任丟出去了，不重構我也樂得輕鬆

資歷是老人，思維跟做事方式像社會新鮮人所以同一間待太久也不好

理解原po的無奈，code落到自己頭上，為了改得動和長久維護的動，願意吃虧花時間去重構，但反而被不是在第一線負責維護的reviewer質疑而覺得沮喪。只能說這種情況是政治和文化問題，開發文化是由有話語權和決策權的人說了算，如果溝通無果，要就加入這種文化，要不心裡的坎過不去的話，那就好好打算吧

你的實力壓不過別戈才會這樣

提到老api xxx 看來你這不是重構唷 改api被打槍不是很合理嗎

推justaID

開新api就好 舊的標deprecated

這行多的是文人相輕api 改spec 出事一定扛不住

用你的新架構有風險 你要從頭維護到底嗎 再來你明顯不夠厲害 找不到root cause以及用最小的改動解決問題

你以為〈只要能動就不要改〉是開玩笑的時候：

做改動前有先向上溝通嗎？或是跨組溝通？獲得同意才做的還是你就直接做下去了?

這代表你在公司credit還不夠吧..夠力的話誰會擋...

溝通能力有待加強 美其名想解決問題 其實只是底層碼農的美好幻想 在產品先行/功能先行的團隊就是這樣也不見得要離職啦 可以找其他方式實現自我 參加程式小作坊之類的 不要用工作來實現理想 那是賺錢的地方

完美無缺是你自認為的，隱藏沒爆的可能比你想像的多

以前的公司發生過，要求重構→開需求→寫完測完→「還能跑就不用換了」，浪費我時間

有給你薪水就沒浪費你時間啦，別學原PO沒事自幹就好

老氣 沒先確認過就自己改了嗎？

如果已經在公司扛這麼久，說明清楚後還不被上頭信任 我是會直接走人

這種上頭的 code review 當耳邊風就好，看有沒有機會加薪繼續忍上頭，或升遷為上頭，沒機會就換了吧

除非你改的地方code base只有你一個人在寫跟維護，多人都會動到的地方你翻掉以前都沒先design review過？改完了才說就是想硬上，本來大家熟悉的東西你確定你改了還有人看的懂？上面要你修bug結果你整個翻掉，時程上都沒人發現？整件事都很怪啊 master大大

拿多少錢做多少事 沒要你做的就別做了

首先 有人叫你重構嗎?沒有幹嘛做

重構你負責的部份就好，重構主要是為了自己後續方便，自己舒服而已，搞太多別人酸被人嫌，正常的剛好說真的不懂設計模式跟oop實際經驗，別跟我提重構兩字，一律當笑話

我最害怕懂設計模式的人了

假如原本市場測了10年，你改完經得起考驗嗎？

耍廢擺爛即可，反正公司不能隨便開除