我想補一個情境
當到新公司或轉到新單位時
發現沒有在做unit test
此時身經百戰寫過上千次unit test的你
會選擇憑一己之力
引入測試框架及補完所有模組的單元測試嗎？
當然這也代表那些高耦合的模組你要想辦法拆分
其中改壞了算你的鍋，改好沒人在乎
而且高機率你得自己維護測試code
還是選擇打不贏就加入？
我很好奇
大家可以分享一下嗎
我自己是選擇不改啦

甚麼叫做一己之力? 甚麼叫做自己選擇? 請開會討論你上面叫你改你就改, 叫你不要改就不用改

你想改本來就要知會主管不是嗎？還是你當的RD沒權力在軟體品質上提意見？

所以團隊如果不支持就不用改了如果團隊支持, 那就不是你的鍋, 也不會沒人在乎

這種工作吃力不討好，除非主管說你考績會變好，不然就算了

是不是99%台灣的公司都不在意code quality?

這種層級的問題我都會議上報上去，主管決定要排誰來改。

沒測試就是直接重寫重寫的時候順便補 上面的人不支持你重寫的話當然就不去動

就….預設的後續其實不會發生，想改一定是提出來討論，討論過了才能動工，那這時怎麼可能都給一個人扛，要馬趁改版時慢慢補，要馬就是慢慢拆出來補，上司一定得跟進度，也不可能讓人隨意影響到實際運行的商品

你一個剛來的菜鳥什麼都不知道，怎麼可能做的出所有測試除非前人有留完整且正確的架構圖給你，我是從未見過啦還有各種獨門秘方藏在某人電腦裡，通常都是主管

你甚麼都不知道要測啥 怎麼寫

沒test的code會有spec給test用? 水星撈到鯨魚機率高一點

一意孤行反而其他不會改UT的一直問你為什麼code CI跑不過

他們不會問你，會直接跟上面說因為你的東西阻礙產出然後你就變成影響公司營收的罪人，KPI完蛋，信用掃地教科書上那些好棒棒的理想留著自己用就好，現實不是這樣

unit test會牽扯到重構，絕不只是寫unit test而已

獨門秘方藏在電腦裡XDDD

新開發的才會用，時間要用對地方，不要只是為了寫而寫

觀察團隊文化而定吧？！

Unit test 絕對要重構 除非原來的dependcies 早就弄好

當然不要寫啊 淌混水幹嘛？測試也是要維護的 沒人寫 後續也沒人要維護 那測試很快變拉機等你離開該單位 你寫的測試又變成別人的麻煩

看上面的老闆會不會加錢，不然弄完被開除怎麼辦還是多寫幾個坑，讓別人踩比較實在

想接這題問：如何能夠提升高層對於 code quality 的重視度？每次碰到前人留下來的屎都很想砸電腦不弄了

去公司外面繞一圈看盡好扣爛扣，提升自己的耐受性然後釋懷

可能發展如下，本來運作好好的系統，因為你補了測試找出潛在問題，另一個是你改壞了。前者可能沒人在意，是後者那你麻煩很大。一是期待別人跟上你的成長，另是產生影響力，也許結果很像，但意義上完全不同。

正解：就把電腦砸了吧 就換工作 不然就自己創業高層老闆會重視程式品質 也不用等到你來講喇 哈

太年輕了啦，做的過程中誰有空告訴你一堆歷史遺留問題的原因，做完了自己沒 credit 反而幫到別人，出問題卻又會變責任中心，幫這種的吃力不討好的事誰愛做？更常見的高手齁，當然是做一頁投影片上報高層說 legacy巴拉巴拉，新的方法可以解決問題，還可以怎樣怎樣更有夢想，說服高層給 resource 重新弄一套，鬥鬥老屁股爬上去當大王啊

能賣錢最重要，你在意的po或許根本沒差

我現在走的就是一，很大的原因是因為我直接對到大主管，他也支持我這麼做

主管沒叫你做就不要做啊，改爛背鍋，改好也沒人感謝你