→ MoonCode: dirty code 比較快我認為只是找藉口掩蓋自己能力不足而 04/10 16:42
→ MoonCode: 已 04/10 16:42
→ MoonCode: 沒什麼大小之分 只有強弱而已 04/10 16:44
dirty code比較快 沒啥好爭議
要做完整的規劃和分析 花的時間就是比較多 慢工出細活
除非你本身已經做過此feature很多遍
至於強弱問題 不如說抉擇問題
→ nekosgr93: 蔡逼八剛進新創也覺得應該要跟大公司一樣有嚴格的開發 04/10 16:46
→ nekosgr93: 流程 04/10 16:46
→ nekosgr93: 要有測試 04/10 16:46
→ nekosgr93: 要建CICD 04/10 16:46
→ nekosgr93: 要clean code 04/10 16:46
→ nekosgr93: 後來才終於醒了 04/10 16:46
→ nekosgr93: 品質都是假的 04/10 16:46
→ nekosgr93: 投資人的錢錢才是真的 04/10 16:46
→ nekosgr93: 除非老闆很有錢或有富爸爸 04/10 16:46
→ nekosgr93: 不然你還在慢慢建流程老闆明天資金就燒完了 04/10 16:46
→ nekosgr93: 建立文化那是在賺錢後才該做的事 04/10 16:46
噓 MoonCode: 沒有CICD 怎麼可能快得起來 沒有測試 你debug花的時間 04/10 16:47
→ MoonCode: 你有辦法評估？ 04/10 16:47
你未來需求會更改的情況下 你寫testing的目的是？
CI/CD或者一些基礎的自動化或style規範 並不在我討論設計系統的範疇
再者 dirty code 可能在某些情況下 還比較好debug
比起那種沒寫好的多重依賴 是爽多了
→ nekosgr93: CICD測試也是要有人去寫有人去維護 04/10 16:48
→ nekosgr93: 大家談自動化都很簡單 04/10 16:48
→ nekosgr93: 可是自動化也是有人要去做的 04/10 16:48
→ nekosgr93: 對於人力資源很吃緊的新創來說是最不應該優先做的事 04/10 16:48
噓 hegemon: 你如果是要做B2B的生意，軟體品質太爛在業界怎麼生存？如 04/10 16:50
→ hegemon: 果是被政府監管的行業，軟體品質更要重視，quick and dir 04/10 16:50
→ hegemon: ty都最後還是要付出代價 04/10 16:50
程式碼寫的髒 跟 產品會不會動 這件事情是兩回事
相信h大在台積電的時候也應該可以完全理解
那這樣說起來M , m 那些程式碼 不就貽笑大方了 XD
噓 MoonCode: 這東西也沒辦法量化 每個人快得方式不一樣 大家都很快 04/10 16:51
→ MoonCode: 不過快然後 其他指標呢 04/10 16:52
業務面先起來 一切好說 否則你把文件搞起來 需求變了 公司倒了 文件要幹嘛
→ nekosgr93: 就像大家都知道文件很重要 04/10 16:52
→ nekosgr93: 規格很重要 04/10 16:52
→ nekosgr93: 但實際上誰要去寫 04/10 16:52
→ nekosgr93: 誰要去維護更新呢 04/10 16:52
→ nekosgr93: 如果你平常忙寫feture忙解bug都來不及了怎麼可能有時 04/10 16:52
→ nekosgr93: 間去管那些 04/10 16:52
→ nekosgr93: 只能說不同公司規模大小做法不同囉 04/10 16:53
→ MoonCode: 有文件大家也確認規格沒問題後 做起來才會快啊 所以我 04/10 16:53
推 lova: 省下的時間就是技術債，就跟大家買房通常會貸款一樣 04/10 16:54
→ MoonCode: 說大家快得方式不一樣 沒有訂好短期驗收目標的東西 04/10 16:54
→ MoonCode: 我不知道能多快 我是很慢啦 04/10 16:54
技術債 不可能避免 你只可能盡量減少 省下來的時間是幫業務面爭取時間
然後我有說 不用基本的spec嗎 XD
※ 編輯: stillboy (1.160.145.196 臺灣), 04/10/2021 17:05:31
→ nekosgr93: 以新創來說需求變動很快的 04/10 16:55
→ nekosgr93: 你花一天寫好的文件可能隔天就通通改掉或甚至不要了 04/10 16:55
→ MoonCode: 就算是 CRUD 前端一樣要先知道怎麼接 沒文件只能通靈 04/10 16:56
→ MoonCode: 那你的這種新創 我沒加入過 只能說辛苦了 04/10 16:56
→ MoonCode: 我也好奇變動這麼快的模式 在業界很常見嗎 04/10 16:57
機率不高。 而且我也強調 要有基礎的spec
推 alihue: 新創需要的是快速迭代，不是隕石開發，如果需求一直毀滅 04/10 16:58
→ alihue: 那BD真的廢 04/10 16:59
理想情況 當然不想要隕石 但17 live剛開始幾年 都是隕石度過
強的BD 可遇不可求
→ MoonCode: 變動如此快 反正也只能是老闆來扛起最後責任 那我避免 04/10 16:59
→ MoonCode: 加入這種公司 04/10 16:59
那你可能適合加入大公司 或者 已經找到確定需求的 高速成長的新創公司
但其實很多時候也在摸索
→ alihue: 專案一直被隕石的，這個新創八成只是接案，哪裡有錢往哪跑 04/10 17:00
→ MoonCode: 接案就不能算新創了吧 我以為新創是有新的商業模式 04/10 17:00
推 alihue: 然後會覺得CICD/測試是慢，根本就是寫程式經驗很菜 04/10 17:05
這樣講太過武斷 一直隕石 某種程度很可能是BD的問題 跟接案無關
※ 編輯: stillboy (1.160.145.196 臺灣), 04/10/2021 17:13:42
推 MoonCode: 我的回覆大部分是針對推文啦 04/10 17:22
→ MoonCode: Dirty code 快 能夠快多久？ 04/10 17:23
沒量過 但我只知道 不寫dirty code 要把一個feature裡裡外外 想通想透 並設計好
時間成本會遠大於寫dirty code
我說這樣 不代表我支持寫dirty code
非常時期非常手段 取捨問題
※ 編輯: stillboy (1.160.145.196 臺灣), 04/10/2021 17:28:01
推 newhandfun: 回Moon大，接案公司也可能是新創 04/10 17:29
→ newhandfun: 可能是要開發商品但沒啥資金燒只好接案過活看啥時有 04/10 17:29
→ newhandfun: 錢開發的公司 04/10 17:29
→ MoonCode: 阿後來公司有做起來嗎 04/10 17:29
有的有 有的沒有 但早已經離開新創圈了
→ MoonCode: 抱歉我是回此文 po 04/10 17:31
推 newhandfun: 沒，我已經逃出來了 04/10 17:31
→ MoonCode: 新創感覺要加入拿到 A 輪後的 開始有穩定商業模式 04/10 17:32
補充一下 很多新創一開始的策略都是
接案(現金流) -> 去養自己想做的產品
除非你是富爸爸 後面有金主 不然 基本上沒有穩定現金流 會是很可怕的
※ 編輯: stillboy (1.169.170.171 臺灣), 04/10/2021 17:35:51
→ MoonCode: 東西品質開始要求 不然 dirty code 我覺得對職涯發展 04/10 17:33
→ MoonCode: 蠻傷的 04/10 17:33
→ MoonCode: 但一切都是薪資問題 想到自己始終是打工仔就懷疑人生 04/10 17:34
所以以你的需求 你應該要近的反而是 大公司 or 有規模以上的高速成長新創
在那邊 你才可能得到你要的東西
選擇比努力重要
※ 編輯: stillboy (1.169.170.171 臺灣), 04/10/2021 17:40:09
→ MoonCode: 就你加入這種超早期新創的經驗 有拿到超過 1% 的期權嗎 04/10 17:41
→ MoonCode: 後來有行權嗎 04/10 17:41
沒超過1% 沒行權。
年輕時，加入新創不是for money
而是覺得很cool 不想加入大公司當螺絲釘 想做出大貢獻
每個人的理由都不同
想清楚就好
※ 編輯: stillboy (1.169.170.171 臺灣), 04/10/2021 17:47:04
→ MoonCode: 非常感謝分享 04/10 17:48
推 MoonCode: 04/10 17:50
推 dmlan1842: 認同原po，我也是有相同感覺！ 04/10 17:57
※ 編輯: stillboy (1.169.170.171 臺灣), 04/10/2021 18:19:12
→ discipile: 新創其實應該找即戰力,本身對feature就有過去的domain 04/10 18:15
→ discipile: knowledge,而不是找菜鳥寫一堆dirty code,在那邊說文化 04/10 18:17
→ discipile: 如此 04/10 18:17
有錢 富爸爸的新創可以
但沒錢的很難 很多甚至都希望你自配電腦 能省則省
而且即戰力資深 願不願意加入一家默默無名的公司 又是另外一個大難題
找菜鳥寫dirty code 接案 有現金流 能驗證商業模式 才有變更好的可能
先活著 再談夢想
※ 編輯: stillboy (1.169.170.171 臺灣), 04/10/2021 18:22:23
→ discipile: 如果新人進入新創就是學到dirty code,那以後只要新人問 04/10 18:22
→ discipile: 大公司還是新創該怎麼選,新人一率大公司 04/10 18:23
→ discipile: 因為讓新人寫dirty code是為了公司生存,但對新人職涯並 04/10 18:23
→ discipile: 不利 04/10 18:23
同上面，如果不想寫dirty code就該避免加入這個時期的新創
對新人而言 他的確可能在這個時期寫了dirty code
而如果幸運的話，
隨著業務的發展 業務開始穩定 他有機會慢慢把自己的程式碼開始重構
而且重構起來會更有心得 而且成就感更大 如果工程Team開始長大
開始找人 有機會帶人 並做出更大的貢獻
這種例子 也不算少
→ leo5916267: 前期需求會不斷變動，又爛又快才是正確的，寫再好都 04/10 18:26
→ leo5916267: 可能要砍掉重寫所以要學著邊寫邊重構，當然壓力扛不 04/10 18:26
→ leo5916267: 住就是亂寫，之後穩定後閒閒沒事寧願看股票也沒心情 04/10 18:26
→ leo5916267: 填坑 04/10 18:26
※ 編輯: stillboy (1.169.170.171 臺灣), 04/10/2021 18:36:01
→ discipile: 公司面怎樣是老闆考量,員工要考量的是自己的職涯跟建議 04/10 18:29
→ discipile: 別人時,對方的職涯規劃 04/10 18:30
考量自己這件事情本身沒有問題
但是如果要做出更具影響力的貢獻
懂的犧牲 站在整個團隊甚至公司的角度
去評估這個決策是否合宜
※ 編輯: stillboy (1.169.170.171 臺灣), 04/10/2021 18:38:20
→ discipile: 我的話中哪裡有質疑為什麼這時期的新創寫dirty code對 04/10 18:38
→ discipile: 不對 04/10 18:38
理解錯誤 已修正有爭議的那一行
→ discipile: 我的那邊就是寫下你的結論,新創這個時期就是dirty code 04/10 18:38
→ discipile: 再來新創做大這件事情回歸台灣新創成功上市比例有多高 04/10 18:39
低到不行。
但上市的這個條件我覺得有點嚴苛 XD
※ 編輯: stillboy (1.169.170.171 臺灣), 04/10/2021 18:45:21
→ discipile: 案例不少,但看整體比例會是多高？ 04/10 18:41
噓 Ghamu: 我目前只待過新創 不同意你的意見 04/10 18:47
→ Ghamu: 特別是我們新創被併購後 更是不同意 04/10 18:47
→ Ghamu: 現在新創被併購 有資源有人 結果拖慢整體進度的人就是我們 04/10 18:50
→ Ghamu: 帶著這種dirty code time to market 但管理方法還在line用 04/10 18:50
→ Ghamu: 記事本 心智圖截圖法需求的老闆 04/10 18:50
→ Ghamu: 現在併購 有jira 有ci cd 工程師也多 結果開個ticket現在還 04/10 18:52
→ Ghamu: 要請人開 不合理主觀的需要求狂發 明明有一堆埋點工具不用 04/10 18:52
→ Ghamu: 老是聽幾使用者意見就帶著團隊花大把時間”去試” 04/10 18:52
→ Ghamu: 晚點回一片好了 04/10 19:10
推 May75504: 十個新創九個雷 04/10 20:42
→ May75504: 可以調查一下新創的裁員比率有多高 04/10 20:44
推 kewang: 完全同意這篇 我剛進來半年左右認為應該要把規矩訂好 架構 04/10 20:54
→ kewang: 寫好 但待了快一年之後 發現完全如同這篇所講。不過我現在 04/10 20:54
→ kewang: 還是先儘量以能架構化為主 如果真的沒辦法就 hard code 或 04/10 20:54
→ kewang: 有點髒也沒關係。這時 mongo 是個很好用的東西了 xd 04/10 20:54
→ lazarus1121: 我比較想知道開發途中有需求變更時，文件會怎樣維護 04/10 21:12
→ lazarus1121: 如果頻繁的維護做白工的機率會很大吧 04/10 21:13
→ nekosgr93: dirty code就看有沒有自覺了 04/10 21:25
→ nekosgr93: 如果是對code品質有要求的我相信就算現在要為了mvp趕 04/10 21:25
→ nekosgr93: 出來也一定會覺得渾身不舒服想要修的更clean 04/10 21:25
→ nekosgr93: 那在產品還沒有變得過大之前就會想辦法慢慢的補技術債 04/10 21:25
→ nekosgr93: 了 04/10 21:25
→ nekosgr93: 而且我覺得dirty code也不是新創專利 04/10 21:25
→ nekosgr93: 很多大公司老專案的code也是髒到不行而且員工還會覺得 04/10 21:25
→ nekosgr93: 能run就好了沒事不要去改他 04/10 21:25
推 labbat: 文件多多益善，解程式碼問題才會順手寫測試改業務程式碼 04/10 21:30
→ red0210: 寫 test 可以確保你寫的東西可靠，速度慢我覺得是錯覺， 04/10 22:09
→ red0210: 終究你都要想辦法測你寫的東西，形式不同而已。 04/10 22:09
→ lazarus1121: 不過會寫dirty code的很大機率不用自己接後續維護 04/10 22:12
→ lazarus1121: 多吃幾次自己拉的屎後就會改進了 04/10 22:13
推 sssh9300662: 原po提的可以理解，但可惜的是很多case也是用這“說 04/10 22:43
→ sssh9300662: 法”但實際上確不符合原po講的情境 04/10 22:43
→ soccer103: 可理解但大家是不是忘了 dirty code 就是債 04/10 22:51
→ soccer103: 而債是會拖累下次的開發速度的 04/10 22:52
→ soccer103: 也許下次快 下下次呢 三個月後再回來改相關 code 呢 04/10 22:52
→ soccer103: 如果公司快速成長 04/10 22:54
→ soccer103: 又沒文件當初寫的人也走了 04/10 22:54
→ soccer103: 那麼新進成員在開發效率上勢必會被拉慢 04/10 22:54
推 CoverMind: 認同 dirty code有時只是時間成本的妥協 沒有一定對錯 04/10 22:55
→ soccer103: 有個極端例子就是均一教育平台 04/10 22:55
→ soccer103: 雖然已經不算新創了但債爆到前陣子要上前後端社團徵求 04/10 22:55
→ soccer103: 志工處理 04/10 22:55
→ CoverMind: 技術債本就是要還的 某些情況你不貸就直接倒 你貸不貸 04/10 22:57
→ soccer103: 處理的債的時間也是成本 04/10 22:57
→ soccer103: 問題新創哪有不忙 04/10 22:57
噓 sharku: dirty code 哪裡有快, 是只能 dirty 來快的程度造成 04/10 23:23
推 accessdenied: 新創有個特性，就是隨時會 pivot ，爛 code 的技術 04/10 23:27
→ accessdenied: 債常常根本不用還，一 pivot 就整坨刪除。關於文件 04/10 23:27
→ accessdenied: 的維護，最好的方式就是沒有文件，然後做到程式碼即 04/10 23:27
→ accessdenied: 文件，註解該寫就寫，commit log 認真寫，這樣就很 04/10 23:27
→ accessdenied: 夠了。 04/10 23:27
→ nekosgr93: 公司沒錢只請得起水電學徒請不起水電師傅那工程弄得醜 04/10 23:39
→ nekosgr93: 一點也是沒有辦法的囉 04/10 23:39
→ nekosgr93: 看學徒有沒有自覺想弄的更完美一點 04/10 23:39
→ nekosgr93: 不然就是等公司賺錢了請師傅來大修 04/10 23:39
→ nekosgr93: 雖然我覺得會被嗆說沒錢就不要出來開公司 04/10 23:39
推 jack0204: dirty code要看程度，不會要求完美，但基本的一定要有 04/11 00:17
→ sharek: 經驗/能力不足才覺得dirty快的起來 04/11 00:47
→ viper9709: dirty code不是不行,但不能一直用dirty code 04/11 00:55
→ nekosgr93: 我覺得有個重點是 04/11 00:59
→ nekosgr93: 不是因為dirty所以才快 04/11 00:59
→ nekosgr93: 是因為快(加上沒錢)所以才dirty 04/11 00:59
推 vi000246: dirty code的確很快 但只建立在不用還技術債的情形上 04/11 01:02
→ nekosgr93: 應該沒有任何一個正常的工程師會想寫義大利麵的 04/11 01:03
推 mirror0227: 看 dirty 程度吧 有時候類似邏輯又還想不到整合 主管 04/11 01:55
→ mirror0227: 也會說先就保留兩個版本 以後 feature 穩定再 refact 04/11 01:55
推 taipoo: 中肯文 04/11 02:31
噓 andykao1213: 不好意思給了個反推，自己待新創的經驗是code qualit 04/11 09:32
→ andykao1213: y太差反而到後期沒辦法快速迭待，也沒辦法快速scale 04/11 09:32
→ andykao1213: up. 重要的是MVP的觀念，如何只做最重要的feature, 04/11 09:32
→ andykao1213: 盡可能把有限的資源做最大化而不是犧牲品質 04/11 09:32
推 tvbic: 如果能學會用標點符號更好 04/11 11:33
推 UniFish: 你戳破某些人的幻想泡泡了 XD 04/11 11:41
推 brianhsu: 推 andykao，和我的經驗一樣，爛 code 一開始看起來很快 04/11 13:49
→ brianhsu: ，但實際上根本沒辦法應付不斷新增和變動的需求。沒 CIC 04/11 13:49
→ brianhsu: D 和自動化測試也是，爛 code 改 A 壞 B 是家常便飯，每 04/11 13:49
→ brianhsu: 天修 bug 就飽了。 04/11 13:49
推 hongsiangfu: 寫Dirty code很好啊,TMD別叫我接著去維護就OK 04/11 14:03
推 Ghamu: 嗯 我發現我有點誤會原po了 推回來 04/11 14:20
推 atpx: code常因為新創面向市場會被廢棄掉的話, 那的確多個CICD沒幫 04/11 18:30
→ atpx: 助 04/11 18:30
→ atpx: 一些極端情況不得不然 04/11 18:31
→ cha122977: Dirty Code也分寫的好不好的 寫的好就是之後要改很容易 04/11 22:05
→ cha122977: 不然一堆Hard code 最好是之後要改比系統化的容易 04/11 22:07
推 ZakuSIN: 每個人的dirty code都不同啊XD 有些比dirty還慘 04/13 17:40
推 travelmat: 推。個人想法這篇其實重點不在細節執行面，比較像是在 04/14 07:45
→ travelmat: 討論新創不同發展階段下的文化也好組織需求也好 04/14 07:46
→ travelmat: 新創很多時候其實是在做POC概念驗證，這時候的重點不在 04/14 07:48
→ travelmat: 你用多漂亮的方法達到目標功能，而是這個功能符不符合 04/14 07:48
→ travelmat: 目標價值，在這種情況下其實只要產品能動不要有大問題 04/14 07:49
→ travelmat: 先驗證功能能夠滿足需求滿足價值，再來討論怎樣優化 04/14 07:50
→ travelmat: 才有意義。 所以重點其實不是程式或方法髒不髒，而是 04/14 07:51
→ travelmat: 如何盡可能用最小的資源去驗證價值 04/14 07:52
→ travelmat: 只是用最小資源的情況下"通常"程式或方法會比較髒而已 04/14 07:53
推 twin2: 推 04/14 10:08
推 OldDaiDai: 推 04/14 18:11
→ abraxas: 開發好像很快，結果脆弱的要死，技術債又一堆，越走越慢 04/15 09:05
推 kongyeah: 這篇好！原原po不爽就噓略失風度，小小格局有限。 04/15 17:34