※ 引述《wandallin (萬大林)》之銘言：
雖然你同事提的是有利後續長期維護程式碼的事務和規則，
但是從大局來看... 你們才剛上線還要再補功能，同時商業模式又還不確定....
也就是說現有運作模式再大修的機會不小，
因此 1,3,4,5,6,7 點有可能做了以後沒多久就變無意義...是否值得令人疑惑。
再從實務來看，你們用的是實現邏輯的速度快，但 bug 相對複雜難追蹤的 js，
這種情況下若沒有新的功能需求，那程式架構沒嚴重問題就不該去動，
免得改完架構是好懂好維護了，卻有地方不小心改壞掉，越改越不穩定....
這樣你跟老闆都會不好向負責的對象交待。
再加上你們沒有人會寫測試，每次改完都要一一手動檢驗成果，很難快速與完整，
這使你們相對不容易檢查出前面那些問題，專案因此曝露在失控的風險中。
最起碼等到有人先引進測試的做法，系統運作邏輯也穩定下來後才適合去落實其他原則。
整體而言，目前的狀況你覺得煩...我覺得合情合理，沒什麼問題啊~
是我的話也會叫他們先指出那些想重構的地方並記在 issue tracker 上，
待時機成熟時再來搞這些東西~

我想說的都被你說了

超級劣幣

「1,3,4,5,6,7 點有可能做了以後沒多久就變無意義」我反對這樣的看法，依照我待過新創的經驗是；現在不弄照正常發展速度一子dirty code就照成一堆模組依賴了。只要瘋狂的加入新功能，又不早早寫測試，就算壓著不做那些事，系統也不會多穩，既然如此不如趁有心早點做好上述那幾點。

同一樓上 一開始架構弄好 以後趕專案能欠的技術債coda也會比較多

現在不做以後真的會做嗎

建議你心態改變下

很多人被趕的時程壓到超緊繃，這樣的確沒時間做就放棄寫測試，但照經驗來看緊繃不會是一時的，所以未來沒機會去改，就整個放棄測試了

有兩句很經典的話，先求有再求好，以及東西沒壞就不要改才不會改壞，第一句出現在前期，第二句用在後期，結果造就了很多負債累累的系統

還有一句話「程式寫的不好又怎麼會寫的快」但我想能真正經歷的才懂吧

1. 可做, 反正不太花時間, 只是也沒什麼立即明顯的功效3. 可以先都不管, 以後想修再修4. 必需做, 但是範圍要挑過, 程度也要有節制,記 tracker 後再加個步驟 - 討論要不要做, 排時程不能全放生往後延5. 同 3, 可以規範新的怎麼寫, 舊的全改就再說6. 可以考慮排專人負責看 tracker 補 test case,順 開發-建置-測試-發佈 的流程 初期不一定要全員參與7. 用個工具做就好, 沒有白費不白費的問題 @@

其實這是白箱的劇情，多寫測試多做重構就可以一起做的很快但是要能夠多寫測試多做重構的前提就是要你寫的夠快。

推這篇

推! 新創還沒開始賺錢就要做重構?! 你同事平常接票不多吧