推 expup: 我想說的都被你說了 04/26 04:17
→ deray: 超級劣幣 04/26 08:30
推 Masakiad: 「1,3,4,5,6,7 點有可能做了以後沒多久就變無意義」我 04/26 08:44
→ Masakiad: 反對這樣的看法，依照我待過新創的經驗是；現在不弄照 04/26 08:44
→ Masakiad: 正常發展速度一子dirty code就照成一堆模組依賴了。只要 04/26 08:44
→ Masakiad: 瘋狂的加入新功能，又不早早寫測試，就算壓著不做那些 04/26 08:44
→ Masakiad: 事，系統也不會多穩，既然如此不如趁有心早點做好上述 04/26 08:44
→ Masakiad: 那幾點。 04/26 08:44
推 vi000246: 同一樓上 一開始架構弄好 以後趕專案能欠的技術債coda 04/26 08:50
→ vi000246: 也會比較多 04/26 08:51
→ jackblack: 現在不做以後真的會做嗎 04/26 09:01
推 WangDaMing: 建議你心態改變下 04/26 09:49
回樓上幾位
其實我不否定開始開發前的架構很重要，我也討厭公司不解決很可怕的程式碼。
我自己就曾經在前公司系統轉換架構時，在規劃時期卡了公司兩週來規劃與實現好維護的架構。
只是我認為他們現在商業模式不確定，老闆也還在找顧客，
實在不是大改架構使系統穩定度冒上一定風險的好時機，
最起碼也等客戶有著落了，確定這是對方要的東西再以此現狀為基礎重構。
另外，前面提的想法只是大方向反對「單純為了重構」而去大改程式，
以及要先準備好自動化測試辦法之後再重構，總而言之不是堅決反對一切重構行為。
事實上最後提到先鑑定出要重構的部分就是為了讓團隊可以未來新增功能時，
若發現會調整到重構目標就可以一併修正。
另外…若近期比較有空，而且怕以後忙到沒空改的話，那也可以先在其他分支
微調較不影響大局的地方，然後再伺機套用
推 jack0204: 很多人被趕的時程壓到超緊繃，這樣的確沒時間做就放棄 04/26 09:51
→ jack0204: 寫測試，但照經驗來看緊繃不會是一時的，所以未來沒機會 04/26 09:51
→ jack0204: 去改，就整個放棄測試了 04/26 09:52
→ t64141: 有兩句很經典的話，先求有再求好，以及東西沒壞就不要改才 04/26 09:54
→ t64141: 不會改壞，第一句出現在前期，第二句用在後期，結果造就了 04/26 09:54
→ t64141: 很多負債累累的系統 04/26 09:54
→ Masakiad: 還有一句話「程式寫的不好又怎麼會寫的快」 04/26 10:16
→ Masakiad: 但我想能真正經歷的才懂吧 04/26 10:17
※ 編輯: dream1124 (118.169.230.235), 04/26/2018 12:01:32
推 lovdkkkk: 1. 可做, 反正不太花時間, 只是也沒什麼立即明顯的功效 04/26 13:46
→ lovdkkkk: 3. 可以先都不管, 以後想修再修 04/26 13:46
→ lovdkkkk: 4. 必需做, 但是範圍要挑過, 程度也要有節制, 04/26 13:47
→ lovdkkkk: 記 tracker 後再加個步驟 - 討論要不要做, 排時程 04/26 13:47
→ lovdkkkk: 不能全放生往後延 04/26 13:47
→ lovdkkkk: 5. 同 3, 可以規範新的怎麼寫, 舊的全改就再說 04/26 13:47
→ lovdkkkk: 6. 可以考慮排專人負責看 tracker 補 test case, 04/26 13:48
→ lovdkkkk: 順 開發-建置-測試-發佈 的流程 初期不一定要全員參與 04/26 13:48
→ lovdkkkk: 7. 用個工具做就好, 沒有白費不白費的問題 @@ 04/26 13:49
推 senjor: 其實這是白箱的劇情，多寫測試多做重構就可以一起做的很快 04/27 10:43
→ senjor: 但是要能夠多寫測試多做重構的前提就是要你寫的夠快。 04/27 10:44
→ viper9709: 推這篇 04/27 23:11
推 CCben: 推! 新創還沒開始賺錢就要做重構?! 你同事平常接票不多吧 04/30 00:13