Re: [請益] 新創剛起步的一些開發疑問

看板Soft_Job作者 (全新開始)時間6年前 (2018/04/26 03:33), 6年前編輯推噓8(8推 0噓 25→)
留言33則, 12人參與, 6年前最新討論串8/8 (看更多)
※ 引述《wandallin (萬大林)》之銘言： 雖然你同事提的是有利後續長期維護程式碼的事務和規則， 但是從大局來看... 你們才剛上線還要再補功能，同時商業模式又還不確定.... 也就是說現有運作模式再大修的機會不小， 因此 1,3,4,5,6,7 點有可能做了以後沒多久就變無意義...是否值得令人疑惑。 再從實務來看，你們用的是實現邏輯的速度快，但 bug 相對複雜難追蹤的 js， 這種情況下若沒有新的功能需求，那程式架構沒嚴重問題就不該去動， 免得改完架構是好懂好維護了，卻有地方不小心改壞掉，越改越不穩定.... 這樣你跟老闆都會不好向負責的對象交待。 再加上你們沒有人會寫測試，每次改完都要一一手動檢驗成果，很難快速與完整， 這使你們相對不容易檢查出前面那些問題，專案因此曝露在失控的風險中。 最起碼等到有人先引進測試的做法，系統運作邏輯也穩定下來後才適合去落實其他原則。 整體而言，目前的狀況你覺得煩...我覺得合情合理，沒什麼問題啊~ 是我的話也會叫他們先指出那些想重構的地方並記在 issue tracker 上， 待時機成熟時再來搞這些東西~ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.169.230.235 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1524684839.A.874.html ※ 編輯: dream1124 (118.169.230.235), 04/26/2018 03:45:03
推
04/26 04:17, 6年前 , 1F
我想說的都被你說了
04/26 04:17, 1F
→
04/26 08:30, 6年前 , 2F
超級劣幣
04/26 08:30, 2F
推
04/26 08:44, 6年前 , 3F
「1,3,4,5,6,7 點有可能做了以後沒多久就變無意義」我
04/26 08:44, 3F
→
04/26 08:44, 6年前 , 4F
反對這樣的看法，依照我待過新創的經驗是；現在不弄照
04/26 08:44, 4F
→
04/26 08:44, 6年前 , 5F
正常發展速度一子dirty code就照成一堆模組依賴了。只要
04/26 08:44, 5F
→
04/26 08:44, 6年前 , 6F
瘋狂的加入新功能，又不早早寫測試，就算壓著不做那些
04/26 08:44, 6F
→
04/26 08:44, 6年前 , 7F
事，系統也不會多穩，既然如此不如趁有心早點做好上述
04/26 08:44, 7F
→
04/26 08:44, 6年前 , 8F
那幾點。
04/26 08:44, 8F
推
04/26 08:50, 6年前 , 9F
同一樓上 一開始架構弄好 以後趕專案能欠的技術債coda
04/26 08:50, 9F
→
04/26 08:51, 6年前 , 10F
也會比較多
04/26 08:51, 10F
→
04/26 09:01, 6年前 , 11F
現在不做以後真的會做嗎
04/26 09:01, 11F
推
04/26 09:49, 6年前 , 12F
建議你心態改變下
04/26 09:49, 12F
回樓上幾位 其實我不否定開始開發前的架構很重要，我也討厭公司不解決很可怕的程式碼。 我自己就曾經在前公司系統轉換架構時，在規劃時期卡了公司兩週來規劃與實現好維護的架構。 只是我認為他們現在商業模式不確定，老闆也還在找顧客， 實在不是大改架構使系統穩定度冒上一定風險的好時機， 最起碼也等客戶有著落了，確定這是對方要的東西再以此現狀為基礎重構。 另外，前面提的想法只是大方向反對「單純為了重構」而去大改程式， 以及要先準備好自動化測試辦法之後再重構，總而言之不是堅決反對一切重構行為。 事實上最後提到先鑑定出要重構的部分就是為了讓團隊可以未來新增功能時， 若發現會調整到重構目標就可以一併修正。 另外…若近期比較有空，而且怕以後忙到沒空改的話，那也可以先在其他分支 微調較不影響大局的地方，然後再伺機套用
推
04/26 09:51, 6年前 , 13F
很多人被趕的時程壓到超緊繃，這樣的確沒時間做就放棄
04/26 09:51, 13F
→
04/26 09:51, 6年前 , 14F
寫測試，但照經驗來看緊繃不會是一時的，所以未來沒機會
04/26 09:51, 14F
→
04/26 09:52, 6年前 , 15F
去改，就整個放棄測試了
04/26 09:52, 15F
→
04/26 09:54, 6年前 , 16F
有兩句很經典的話，先求有再求好，以及東西沒壞就不要改才
04/26 09:54, 16F
→
04/26 09:54, 6年前 , 17F
不會改壞，第一句出現在前期，第二句用在後期，結果造就了
04/26 09:54, 17F
→
04/26 09:54, 6年前 , 18F
很多負債累累的系統
04/26 09:54, 18F
→
04/26 10:16, 6年前 , 19F
還有一句話「程式寫的不好又怎麼會寫的快」
04/26 10:16, 19F
→
04/26 10:17, 6年前 , 20F
但我想能真正經歷的才懂吧
04/26 10:17, 20F
※ 編輯: dream1124 (118.169.230.235), 04/26/2018 12:01:32
推
04/26 13:46, 6年前 , 21F
1. 可做, 反正不太花時間, 只是也沒什麼立即明顯的功效
04/26 13:46, 21F
→
04/26 13:46, 6年前 , 22F
3. 可以先都不管, 以後想修再修
04/26 13:46, 22F
→
04/26 13:47, 6年前 , 23F
4. 必需做, 但是範圍要挑過, 程度也要有節制,
04/26 13:47, 23F
→
04/26 13:47, 6年前 , 24F
記 tracker 後再加個步驟 - 討論要不要做, 排時程
04/26 13:47, 24F
→
04/26 13:47, 6年前 , 25F
不能全放生往後延
04/26 13:47, 25F
→
04/26 13:47, 6年前 , 26F
5. 同 3, 可以規範新的怎麼寫, 舊的全改就再說
04/26 13:47, 26F
→
04/26 13:48, 6年前 , 27F
6. 可以考慮排專人負責看 tracker 補 test case,
04/26 13:48, 27F
→
04/26 13:48, 6年前 , 28F
順 開發-建置-測試-發佈 的流程 初期不一定要全員參與
04/26 13:48, 28F
→
04/26 13:49, 6年前 , 29F
7. 用個工具做就好, 沒有白費不白費的問題 @@
04/26 13:49, 29F
推
04/27 10:43, 6年前 , 30F
其實這是白箱的劇情，多寫測試多做重構就可以一起做的很快
04/27 10:43, 30F
→
04/27 10:44, 6年前 , 31F
但是要能夠多寫測試多做重構的前提就是要你寫的夠快。
04/27 10:44, 31F
→
04/27 23:11, 6年前 , 32F
推這篇
04/27 23:11, 32F
推
04/30 00:13, 6年前 , 33F
推! 新創還沒開始賺錢就要做重構?! 你同事平常接票不多吧
04/30 00:13, 33F
‣ 更多 dream1124 的文章
文章代碼(AID): #1QuDWdXq (Soft_Job)
討論串 (同標題文章)
完整討論串 (本文為第 8 之 8 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共8篇)
‣ 更多 dream1124 的文章
文章代碼(AID): #1QuDWdXq (Soft_Job)