※ 引述《Lordaeron (Terry)》之銘言：
: ※ 引述《HZYSoft (PCMan)》之銘言：
: : 如果有在好好追蹤技術債，定期償還，視情況舉債，有時是一件好事情。
: : 重點 hard code 的當下要留下註解，說明前因後果，並且開 bug 追蹤，
: : 這樣日後不會忘記，要 refactor 也比較好搜尋到這些位置
: : 補充:
: : 註解的使用不是我想回的重點，重點是平衡短期和長期效益
: : 按照當下的狀況，調整開發的步調。
: : 建議註解單純是加個 TODO: 的註記日後才不會忘了 cleanup
: : 或是有些緊急的修改有當下的時空背景，怕一忙沒法馬上清
: : 日後有空要 refactor 的時候，回想不起來當時狀況。
: : 註解不是描述 code 做了什麼，而是描述為什麼會有這 hack
: : 至於 code 做了什麼，自然是 code 寫好讀 code 就懂了
: 都說是做專案了，又不是做產品。
: 做專案當然是做完收錢，Meet Dealine，所以重點是，
: 照案主的需求，改成他要的，照資安需求，修掉有問題的地方。好好上線。
: 一案結束，就下一案來了，你還有空refactor? 誰billing你？
: 我是真的不明白ptt 上一堆天天refactor 掛嘴邊的。
: 用數字說話吧，台灣是出了幾個產品？ 幾個open source project ?
: 大家不就接案或做公司內部PROJECT。
: 你一個人爽refactor 讓其他人陪你一起更版，就真的是一個老闆的現象囉。
再吐一下天天refactor 的，在台灣你可以看到一堆公司，都有自己的產品，
就是接案子後，用原案的CODE重包出來的：產品。
然後，根本賣不動，這樣要你老闆BILLING你的閒著沒事做去re-fat-tor?
號稱精進系統，使系統更好what?
這下問題大了，何謂"更好"？如何衡量？
跑更快？算更準？資源吃更少？更容易讀？
如果哪一項是為了讓產品更有市場競爭力的也就算了，
公司還可能BILLING你去 fat 一下。然後再BILLING 大伙又重測一次。
最後，注解不寫一下這段CODE 的作用，只寫為什麼這樣HACK，就去將哪個人
鞭十下。
誰管你說的好讀、不好讀，你是讀得懂李白還是杜老爺，誰第一誰第二是不是？
又不是在寫詩詞歌賦。

哈哈哈哈哈哈哈哈哈

已經上線的案子 敢re的不多 通常是re給之後的案子用 另外re不re 也跟職場政治有關係

只錢有關，政治就是錢，錢不是萬能，但沒錢萬萬不能。

上班就是為了錢 沒什麼問題不重構 有空review下也是好事 可以睡得安穩點 曾經就在屎山中找到暗藏5年的大bug 一直有人不定期暗中使用獲利

其實要不要 re 問自己內心即可，不用問過老闆更不用經過老闆同意，自然也沒有kpi 或績效問題。只要問自己，re 過之後會不會讓未來的工作感覺更輕鬆或帶來成就感自我感覺更開心？會就 re，不會就睡覺，反正自己內心那關都過不了，就算老闆加薪要求你 re 你也 re 不出個鳥來。要不要 re 從來就跟外在環境無關，就看自己願不願意而已。反正老闆看你上班打鍵盤，也不知道你是在 re還是在 ptt 打廢文。

原來你re 完不用重測？你不要求人家billing 你，然後你fat 完,自己負責測完且其他人同意，就是囉

不要講那個幹話 我底下的rd如果沒經過我同意就自己在那邊refactor我一定把他抓出來幹上天 什麼叫做不用問 什麼叫做追求自我成就感？ 想要自己想幹什麼就幹什麼麻煩自己開業當老闆

要不要 re 本來就是個內心爽度的問題，什麼測不測 billing 不 billing 的都是其次。只能說樓上的文化不適合，愛 re code 的人根本不可能去樓上當你底下的rd。啊，樓上你醒醒，看清楚你底下根本沒有 rd。

都出來上班了，所有在公司內程式碼都不是屬於你個人的.不是你說要refactor 就可以...程式碼是屬於公司跟股東的好嗎公司跟股東沒有允許，你就是不能psuh上去尤其是已經上線的code 你亂refactor 真的出事影響範圍很恐怖如果是某個客戶已經在量產的firmware 你refactor 完真的出事的話，客戶產線停工損失你要扛嗎？

修改上版都有對應的任務單吧？怎麼還會有未經同意重構的疑慮

有些人會在feature 或是bug單上順便做不必要的refactor另外有些老人不喜歡走ticketing system

個人經驗，我寫的程式碼在我離職前根本不會有人管，所以我怎麼re基本上是我的事情單元測試跟整合測試都我寫的，就想不想做而已

說實在的，沒人要管你的code，大家都只看結果而已。如果你收一張單，沒上ptt 發廢文，順便fat 一下，然後整合測試又過了，過版後也沒影響到原來的資料，當然是沒人有意見啊。你又fat 又不發廢文。但只要你fat 又有錯的話，就準會被鞭十下。

其實比較龜毛的環境是會要你解釋為何產生這樣結果 即使正確

一開始就特攻的專案 code 想產品化自然是緣木求魚了

就軟體的發展史來說，就是偉大的ORACLE，也是專案的產物，畢境誰都要生存。但生存得要有剩，願意投下資金在台灣當然是木魚緣求。因為做代理更香。小故事：當年宏碁施先生，投資了一個網路棋牌遊戲的公司，也有開發各種非賭博的棋牌遊戲，這時就是各位fat 大神該去的公司了！但當時網路遊戲還不盛行，大家最多就是看看相簿。雖然他們的程式，是真的要找這邊的重肥人來重肥一下的，但也真心在開發。一過快十年。公司賣盤了，不玩了。沒多久，網遊就火了，大家都網了

緣木求魚啦

版上水準怎麼這樣,成語還能弄反?

有趣

Code都寫不好了 你確定它的註解會好讀？

只要你持續開發 屎山絕對讓你力不從心 做這種事情當然是為了自己好 你不當基層或保飯碗的想法當然覺得沒必要 這種事情一開始就做後面花時間就少 不能一勞永逸就不是好東西 有整自然也沒有天天重構的必要 所有東西都在控制中產品質量也好有做到當然不用花大把時間重構你嫌你自己頭髮太多可以每天花很多時間在理解code

我好奇一下,superpandal是負責哪家哪個產品的呢?

他怎麼可能會說

這種議題就是看待在那個產業、部門、老闆、主管之下，哪種環境造就哪種人……..阿不是，是造就哪種code

當然阿，大型開源一堆隨便一個issue就討論超久，code

refractor 很好呀 有時間員工想作 有何不可 反正還有jenkins裡各種的test去把關 都過了測試 那有啥問題?

看來很多人都是老闆。讓他手下的員工想如何就如何東西還不用管上線，只要什麼S 過就好的。看來公司大不怕賠。

有啊 你 fat 完之後打到一個沒測到的問題炸掉客戶資料業務去道歉的時候 嘻嘻你可以說那是測試的需求沒開好干我屁事然後看看老闆表情

「只要它能運作，就不要動它！」我相信只要做的夠久就能明白這句話有多重要...

坦白說在那邊肥來肥去對職涯一點幫助都沒，還不如把時間拿去準備面試面試談到你做的專案沒有亮點可不會因為你肥得很好就加分面試官只會覺得你們一開始就該寫好^^

我之前面試工程主管的缺..對方公司創辦人只關心做過的專案為原公司帶來多少利益...根本不管你用啥技術或寫得多乾淨對方還是個英國佬

看來這篇樓主Ｌ才是真老闆，才會這麼怕公司賠錢。我們這種每個月領固定薪資的，當然要天天練習 re code，反正這間公司只是練 re code的跳板，是步上成大神之路的踏腳石，只要每個月薪水按時進來，公司賠錢乾我屁事？哈哈哈哈！

重構要有價值啦 當改東西發現要到處改還到處漏 加同類型功能每次卻要花一樣多甚至更多時間 自然就會去重構而且本來就要改東西了 重不重構都是要測 也沒有啥陪你重測問題出現

如果是跟著需求變動還情有可原，有些是假會明明沒有修改需求硬要重構

只要能運作就不要動它+1

公司賠錢你可能沒感覺，但哪天你同事這樣雷你，就不要哭，不過沒事，反正都說要遲早要跳船了，被雷就高歌離席。

我看過有在refactor的都是對自己產出有要求的，要麼都花自己的時間做，或者專案空檔抓個時間做。除非真的閒到不行才會跟主管提案專門做重構，但是公司如果讓你一直閒到這種程度要擔心不是重不重構……

管理問題怪在重構身上？

還在吵啊

工程師能閒到有時間去重構之前的程式碼不是公司太養老就是沒新專案。太養老重構沒意義；沒新專案還是快點繞跑比較好

說重構太閒肯定是夕陽產品 看留著養老或早早換組換工作好的管理至少10~20%時間是花在非需求性開發上

非需求性開發是什麼？為啥好的管理要花10～20%時間在這上面？

這篇就純嘴砲前面那個M文, 你真的有心就去找技術債管理

理想上10~20%花在非需求性的重構跟研究...現實裡大部分的人有這種時間不如早點下班

@alan3100 過我手的系統的數量，相信比你一背子多的了

也許是吧 但你肯定不是好公司或好主管

一定不好。我只看結果，有固定標準。不談宗教式的東西

沒這種二分法，而且時間也是要花在刀口上...

我負責的專案會有甲方工程師一起開發，但他們工程師的程度讓人不敢恭維，但我只重構有重疊的部分，其他地方我才不敢動，有問題他們自己負責