Re: [問卦] 「Cubo Ai 寶寶攝影機」真的不行了嗎？
看到推文提到重構，我想說的是
在台灣，重構，本來就是做功德
你今天發現公司的軟體技術債多到靠盃，
人家花一天就能搞定的功能你們公司要花三天，
換句話說，公司浪費了接近七成的工程師薪水在技術債上。
聽上去很值得重構是不是？
重構完畢公司的效率直接三倍。
所以你要花多久去重構？
答案是，這種能讓時間差到三倍的爛帳，
從討論架構起到QA結束最理想也至少要花半年；
這還是你的TEAM從上到下都腦子夠用
又不會搞一些軍隊折豆腐之類的面子工程的情況。
換句話說，公司至少要忍受半年沒有進度，
你覺得老闆能接受嗎？
最糟的是你甚至沒辦法保證效率會上升非常明顯。
所以你真要重構也只能先計劃好，平時做一些微重構。
但這種重構就像溫水煮青蛙，是完全看不到明顯成效的。
老闆只會覺得，啊幹全隊都做很快，
而且越做越快(得益於你的重構)，
只有你不知道在拖三小(因為要重構)，
你今年的年終就沒了。
所以別重構了，以後有這種問題，
直接忽悠你的老闆開新產線，
一開始就把事情做好，又快又賺錢，
舊產品就放著給他爛。
--
這篇正確 新創最好是有那個資源給妳重
構
重構最大問題是，不能保證你重構完就是好的
更大的可能是二代目屎山
花了半年、一年、花錢花大力氣重搞，之後更
新個兩次，就是大便一坨
這個其實是很明顯的導火索
難怪台灣app都做的那麼爛
更糟但更常見的可能是，你的重構真的
非常完整又精妙，就是同事不會用，但
他們不會來問你怎麼用，而是直接照以
前那樣不管OpenClose原則挖開程式碼
給你寫特例，寫完特例其他的功能就炸
，炸了他們就挖開更多地方寫更多的特
例。個人感覺出現屎山二代的問題至少
有四成是這麼來的。
看文章有提過砍掉重練啊 但是被否決了
腦子夠用QQ 很現實的問題
真的
似乎有道理
簡單的就是砍掉重練比較有效率
舊的就放牛吃草
我跟你們講，自從我有個寫了一百多行
Comment的模組，被討厭IoC的同事挖開
來用特例改的面目全非後，我就不對大
團隊內的重構這件事情抱什麼期待了，
浪費時間
現在這堆大便就同一夥人搞出來的，怎麼會覺
得重寫就會完整，很簡單的道理，有雄心壯志
很好，但是現實理想是有很大差距的，不要說
協同作業，幾個月前、幾年前的我跟現在的我
，做法都不會一樣，我自己有時候要改，都想
不起我之前幹了什麼蠢事
最後能動就好，不要手賤
這產品的功能和規模，我不認為有
大到不能重構
自從我看到我一個function 好幾千行裡面還
有sql語法 我就閉嘴了
底層都用同樣東西 開新產線換湯不換藥
沒人敢保證寫出來的作品沒bug,，程式碼
越多，功能越複雜，
能重寫的機會越低，除非有多一倍的人手
來研發除錯
樓上講的應該不適用此案的背景~
架構太老舊 很可能就是砍掉重練又快又好
然後看起來不是同一夥人搞出來的 開頭的
有其它元老之前就已經離開了
跟柯P講過一樣啊，要重開機
技術長要自己下去寫程式很不尋常好嗎
看104他們的後端是node.js，這語言小眾
其實重構的重點一半在維持，就像你的
難找人，要寫好也不容易
房間一樣，自己不愛乾淨買再多收納櫃
也只是在堆垃圾
JavaScript 不算小眾
因為沒在語言上做類別檢查所以難自發
性寫好是真的，但JavaScript不是什麼
小眾語言
我是指用在後端，比起java,C#,python
呃抱歉沒看到
技術長一人扛硬體 之後又跳下來寫程式.
…後端為什麼會用JavaScript？
我還在用twitter小鳥圖案時的App 功能正常
很多服務長時間沒更新 也OK吧
老闆開什麼垃圾會議就浪費一個下午了
開發一大堆無用的新功能 比重構恐怖多了
台灣不就抄抄抄
同團隊怎麼蓋也是垃圾場 不會變棒球場
自從我看完這篇推文後我對台灣軟體工程師
的軟爛廢物模樣有了全新層次的認知
台灣軟體工程師光是用抄的也可以爛成這樣
怪不得台灣只剩台積電可以出國打天下了XD
![[問卦] 「Cubo Ai 寶寶攝影機」真的不行了嗎？](https://i.imgur.com/4ktnb80b.jpeg "[問卦] 「Cubo Ai 寶寶攝影機」真的不行了嗎？")
35
[討論] 重構跟kpi的考量假設以下情境 有個功能A、B都會用到相同邏輯，且有兩份重覆的code (沒有unit test保護，而且年久失修 要加入unit test會需要更多時程) 現在要加入C，也會用到相同邏輯 身為合格的工程師 應該會把ABC重覆的部份提取出來26
[討論] 重構之前要寫測試 不然不要重構想想這應該算是一種迷思吧 理論上是這樣沒錯 但事實上之前都沒寫測試了 你怎麼證明他之前是對的呢? 所以我大多都直接給他改下去26
[請益] 這種情況要怎麼重構我現在遇到一個情況 同時跟其他人開發很相似的功能 舉例來說 我跟B同時開發兩個電商網站 一個叫博客來，一個叫蝦皮好了 B已經建好博客來商品列表頁面 我也要建立蝦皮的商品列表 想把B建的博客來頁面拿來用24
重構的幾個迷思覺得最近很多文章都有些不求甚解的問題，來寫點論述。 1. 重構不是什麼了不起的事情 2. 變更程式碼，重寫舊的程式碼成自己爽的樣子，不一定是重構。 3. 重構是一種相對安全的工具型開發方法論， 但仍然有不少風險跟誘惑。18
[心得]以策略模式重構switch case或if (影片)最近在客戶那邊一起 pair 重構 legacy code， 碰到了一大段 if/else statement，用來判斷什麼時候該使用哪一種cache， 並依照不同 cache 的邏輯來決定回傳的內容。 發現還是有蠻多風氣比較封閉的公司對這類型的基本功跟處理不是很熟悉， 可能是對 code smell 不熟，對重構不熟，對 design pattern 不熟，對工具不熟。![[心得]以策略模式重構switch case或if (影片)](https://img.youtube.com/vi/zO-NnNC-xyg/mqdefault.jpg "[心得]以策略模式重構switch case或if (影片)")
16
Re: [請益] 這種情況要怎麼重構1. 你不應該去動別人開發中的 code, 除非 pair 或你是有被授權的人. 2. 你可以使用他的 code , 建 common, 但你不應該改回他的部分(理由1). 3. 假設改完會有衝突, 那表示你做的不是重構. 4. 如果完成再重構會花更多時間, 那表示你做的不是重構. 5. 你要用他的 code , 跟你要整理重構, 是兩回事.15
Re: [請益] 這種情況要怎麼重構我這篇寫的跟原原PO的狀況無關 ※ 引述《tbpfs ( )》之銘言： : 其實我真的不懂為什麼要急著重構 : 有好處嗎? : 一般而言，重構都是發生在農閒的時候3
Re: [請益] 這種情況要怎麼重構其實我真的不懂為什麼要急著重構 有好處嗎? 一般而言，重構都是發生在農閒的時候 就是沒有新案子在趕，老闆又要想辦法把人力資源給排滿 以免被上面丟一坨賽過來的最好理由2
Re: [請益] 這種情況要怎麼重構如果專案有deadline的壓力建議是先各自發展以不相互影響為前提，最後再用剩餘時間開 一個分支做重構。其實這就是在規劃專案時沒有一個主要主導的設計人，沒有定義從系統 到功能的分工，導致代碼重工，而且缺乏溝通。 真的建議未來有機會在主導你還是要自己學會定義好工作，先學習不寫code就可以訂出功 能以及架構。我自己工作後常常遇到工程師很喜歡自幹，還沒開始就急著寫code，而不是2
Re: [討論] 重構之前要寫測試 不然不要重構人生在世，吃飯跟拉屎都是要做的，應該沒有人會說， 要先吃飯不然別拉屎，還是先拉屎不然別吃飯。 改扣就是改扣，框個名字自稱叫重構， 是不是不知道，但即使是重構，本質還是改扣。 測試是為了改扣順利，不寫測試還是可以改扣。
![Re: [請益] 這種情況要怎麼重構](https://yt3.ggpht.com/ytc/AMLnZu8OJyPPVMQ7ijoc9ewwrNysCZr1NWZr4Bwqeo5H_Fk=s900-c-k-c0x00ffffff-no-rj "Re: [請益] 這種情況要怎麼重構")