PTT職涯區 / Soft_Job (軟體人)

Re: [心得] 加入新創如何避免踩雷

看板Soft_Job (軟體人)作者 (joey)時間3年前 (2021/04/10 16:15), 3年前編輯推噓23(29推 6噓 147→)
留言182則, 39人參與, 3年前最新討論串5/16 (看更多)
新人加入新創如何避免踩雷 新人加入大公司如何避免踩雷 老實說 有答案？ 新創 和 大公司 不管是環境 或者 能發揮的影響力 或者 風景..etc 都完全不一樣 人生這麼短暫 都看看不好？ 在新創練功完去大公司被電 難道大公司練功完去新創不會被電??? 但 就如上面說明的 環境需求一堆都在不一樣的基準點 那討論誰電誰 有意義？ 因為你可以找到一個例子 我也可以找到一個反例 那就代表你的論述是不一定會成立 最後討論dirty code的問題 『dirty code 存在 取決於 目前業務端的情況和屬性 』 對於連自己客戶是誰都還不確定的新創而言 dirty code 我認為是有必要存在的 但不是100%的code base都是dirty code 而是有時候你必須要睜一隻眼閉一隻眼 我覺得 你既然要來新創 你必須要來了解新創的本質 怕熱 就不要進廚房 這是心態沒有調整好的問題 新創最重要的是什麼？ 是生存，是找到客戶付錢 好讓公司和員工活下去 我發現很多從大公司過來的主管或資深工程師 很下意識的把他們之前在大公司的習慣帶過來 例如 開發流程系統化 系統設計要嚴格 ...etc 但 創過業 或 待過早期創業團隊的人 應該都會知道 老闆知道前面有三條路 但真正是哪條 他自己也不完全確定 所以根據客戶的需求更動 或者 甚至整坨功能打掉 在新創圈 屢見不鮮 在這種需求快速變動的情況下 做嚴格的系統設計 有時會造成 需求調整時的巨大成本 所以就會發生 BD會怪工程那麼慢 工程會怪BD在那邊亂改需求 到頭來 根本原因 就是那些主導工程策略的人 自己不專業 還不自知 什麼樣業務規模 取決於下什麼樣的工程決策 沒有BD面 管你系統設計在棒 根本毫無意義 所以不要怪老闆 就是要快 dirty code也無所謂 因為他看的事情是生存問題 工程本來就是盡量跟BD面 配合 而不是起衝突 出社會也滿多年了 很多事情 不管你在哪一個scale的公司 你面對事情 的心態絕對是最重要的 互相理解 互相站在對方的立場去想 努力做對的事 少抱怨 看到太多人 出社會很多年 自省的能力也沒有培養起來 靠北靠母 都是They的錯 然後這種人 最後 你會發現 很明顯的就是自然而然 會在這個列車上 被多數人決定 放逐的人 結論 想加入大公司就去大公司 想加入新創就去新創 這世界的規則 就是 有些人特別幸運 有些人特別賽 考慮再多 老天爺一個突然安排 你還是無法控制 把自己的心態調整好 把 順利 / 不順 當作人生的風景 你只是過客 你會快樂多一些 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.160.145.196 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1618042552.A.F46.html
→
04/10 16:42, 3年前 , 1F
dirty code 比較快我認為只是找藉口掩蓋自己能力不足而
04/10 16:42, 1F
→
04/10 16:42, 3年前 , 2F
已
04/10 16:42, 2F
→
04/10 16:44, 3年前 , 3F
沒什麼大小之分 只有強弱而已
04/10 16:44, 3F
dirty code比較快 沒啥好爭議 要做完整的規劃和分析 花的時間就是比較多 慢工出細活 除非你本身已經做過此feature很多遍 至於強弱問題 不如說抉擇問題
→
04/10 16:46, 3年前 , 4F
蔡逼八剛進新創也覺得應該要跟大公司一樣有嚴格的開發
04/10 16:46, 4F
→
04/10 16:46, 3年前 , 5F
流程
04/10 16:46, 5F
→
04/10 16:46, 3年前 , 6F
要有測試
04/10 16:46, 6F
→
04/10 16:46, 3年前 , 7F
要建CICD
04/10 16:46, 7F
→
04/10 16:46, 3年前 , 8F
要clean code
04/10 16:46, 8F
→
04/10 16:46, 3年前 , 9F
後來才終於醒了
04/10 16:46, 9F
→
04/10 16:46, 3年前 , 10F
品質都是假的
04/10 16:46, 10F
→
04/10 16:46, 3年前 , 11F
投資人的錢錢才是真的
04/10 16:46, 11F
→
04/10 16:46, 3年前 , 12F
除非老闆很有錢或有富爸爸
04/10 16:46, 12F
→
04/10 16:46, 3年前 , 13F
不然你還在慢慢建流程老闆明天資金就燒完了
04/10 16:46, 13F
→
04/10 16:46, 3年前 , 14F
建立文化那是在賺錢後才該做的事
04/10 16:46, 14F
噓
04/10 16:47, 3年前 , 15F
沒有CICD 怎麼可能快得起來 沒有測試 你debug花的時間
04/10 16:47, 15F
→
04/10 16:47, 3年前 , 16F
你有辦法評估？
04/10 16:47, 16F
你未來需求會更改的情況下 你寫testing的目的是？ CI/CD或者一些基礎的自動化或style規範 並不在我討論設計系統的範疇 再者 dirty code 可能在某些情況下 還比較好debug 比起那種沒寫好的多重依賴 是爽多了
→
04/10 16:48, 3年前 , 17F
CICD測試也是要有人去寫有人去維護
04/10 16:48, 17F
→
04/10 16:48, 3年前 , 18F
大家談自動化都很簡單
04/10 16:48, 18F
→
04/10 16:48, 3年前 , 19F
可是自動化也是有人要去做的
04/10 16:48, 19F
→
04/10 16:48, 3年前 , 20F
對於人力資源很吃緊的新創來說是最不應該優先做的事
04/10 16:48, 20F
噓
04/10 16:50, 3年前 , 21F
你如果是要做B2B的生意，軟體品質太爛在業界怎麼生存？如
04/10 16:50, 21F
→
04/10 16:50, 3年前 , 22F
果是被政府監管的行業，軟體品質更要重視，quick and dir
04/10 16:50, 22F
→
04/10 16:50, 3年前 , 23F
ty都最後還是要付出代價
04/10 16:50, 23F
程式碼寫的髒 跟 產品會不會動 這件事情是兩回事 相信h大在台積電的時候也應該可以完全理解 那這樣說起來M , m 那些程式碼 不就貽笑大方了 XD
噓
04/10 16:51, 3年前 , 24F
這東西也沒辦法量化 每個人快得方式不一樣 大家都很快
04/10 16:51, 24F
→
04/10 16:52, 3年前 , 25F
不過快然後 其他指標呢
04/10 16:52, 25F
業務面先起來 一切好說 否則你把文件搞起來 需求變了 公司倒了 文件要幹嘛
→
04/10 16:52, 3年前 , 26F
就像大家都知道文件很重要
04/10 16:52, 26F
→
04/10 16:52, 3年前 , 27F
規格很重要
04/10 16:52, 27F
→
04/10 16:52, 3年前 , 28F
但實際上誰要去寫
04/10 16:52, 28F
→
04/10 16:52, 3年前 , 29F
誰要去維護更新呢
04/10 16:52, 29F
→
04/10 16:52, 3年前 , 30F
如果你平常忙寫feture忙解bug都來不及了怎麼可能有時
04/10 16:52, 30F
→
04/10 16:52, 3年前 , 31F
間去管那些
04/10 16:52, 31F
→
04/10 16:53, 3年前 , 32F
只能說不同公司規模大小做法不同囉
04/10 16:53, 32F
→
04/10 16:53, 3年前 , 33F
有文件大家也確認規格沒問題後 做起來才會快啊 所以我
04/10 16:53, 33F
推
04/10 16:54, 3年前 , 34F
省下的時間就是技術債，就跟大家買房通常會貸款一樣
04/10 16:54, 34F
→
04/10 16:54, 3年前 , 35F
說大家快得方式不一樣 沒有訂好短期驗收目標的東西
04/10 16:54, 35F
還有 107 則推文
還有 17 段內文
→
04/11 00:59, 3年前 , 143F
我覺得有個重點是
04/11 00:59, 143F
→
04/11 00:59, 3年前 , 144F
不是因為dirty所以才快
04/11 00:59, 144F
→
04/11 00:59, 3年前 , 145F
是因為快(加上沒錢)所以才dirty
04/11 00:59, 145F
→
04/11 00:59, 3年前 , 146F
04/11 00:59, 146F
推
04/11 01:02, 3年前 , 147F
dirty code的確很快 但只建立在不用還技術債的情形上
04/11 01:02, 147F
→
04/11 01:03, 3年前 , 148F
應該沒有任何一個正常的工程師會想寫義大利麵的
04/11 01:03, 148F
推
04/11 01:55, 3年前 , 149F
看 dirty 程度吧 有時候類似邏輯又還想不到整合 主管
04/11 01:55, 149F
→
04/11 01:55, 3年前 , 150F
也會說先就保留兩個版本 以後 feature 穩定再 refact
04/11 01:55, 150F
推
04/11 02:31, 3年前 , 151F
中肯文
04/11 02:31, 151F
噓
04/11 09:32, 3年前 , 152F
不好意思給了個反推，自己待新創的經驗是code qualit
04/11 09:32, 152F
→
04/11 09:32, 3年前 , 153F
y太差反而到後期沒辦法快速迭待，也沒辦法快速scale
04/11 09:32, 153F
→
04/11 09:32, 3年前 , 154F
up. 重要的是MVP的觀念，如何只做最重要的feature,
04/11 09:32, 154F
→
04/11 09:32, 3年前 , 155F
盡可能把有限的資源做最大化而不是犧牲品質
04/11 09:32, 155F
推
04/11 11:33, 3年前 , 156F
如果能學會用標點符號更好
04/11 11:33, 156F
推
04/11 11:41, 3年前 , 157F
你戳破某些人的幻想泡泡了 XD
04/11 11:41, 157F
推
04/11 13:49, 3年前 , 158F
推 andykao，和我的經驗一樣，爛 code 一開始看起來很快
04/11 13:49, 158F
→
04/11 13:49, 3年前 , 159F
，但實際上根本沒辦法應付不斷新增和變動的需求。沒 CIC
04/11 13:49, 159F
→
04/11 13:49, 3年前 , 160F
D 和自動化測試也是，爛 code 改 A 壞 B 是家常便飯，每
04/11 13:49, 160F
→
04/11 13:49, 3年前 , 161F
天修 bug 就飽了。
04/11 13:49, 161F
推
04/11 14:03, 3年前 , 162F
寫Dirty code很好啊,TMD別叫我接著去維護就OK
04/11 14:03, 162F
推
04/11 14:20, 3年前 , 163F
嗯 我發現我有點誤會原po了 推回來
04/11 14:20, 163F
推
04/11 18:30, 3年前 , 164F
code常因為新創面向市場會被廢棄掉的話, 那的確多個CICD沒幫
04/11 18:30, 164F
→
04/11 18:30, 3年前 , 165F
助
04/11 18:30, 165F
→
04/11 18:31, 3年前 , 166F
一些極端情況不得不然
04/11 18:31, 166F
→
04/11 22:05, 3年前 , 167F
Dirty Code也分寫的好不好的 寫的好就是之後要改很容易
04/11 22:05, 167F
→
04/11 22:07, 3年前 , 168F
不然一堆Hard code 最好是之後要改比系統化的容易
04/11 22:07, 168F
推
04/13 17:40, 3年前 , 169F
每個人的dirty code都不同啊XD 有些比dirty還慘
04/13 17:40, 169F
推
04/14 07:45, 3年前 , 170F
推。個人想法這篇其實重點不在細節執行面，比較像是在
04/14 07:45, 170F
→
04/14 07:46, 3年前 , 171F
討論新創不同發展階段下的文化也好組織需求也好
04/14 07:46, 171F
→
04/14 07:48, 3年前 , 172F
新創很多時候其實是在做POC概念驗證，這時候的重點不在
04/14 07:48, 172F
→
04/14 07:48, 3年前 , 173F
你用多漂亮的方法達到目標功能，而是這個功能符不符合
04/14 07:48, 173F
→
04/14 07:49, 3年前 , 174F
目標價值，在這種情況下其實只要產品能動不要有大問題
04/14 07:49, 174F
→
04/14 07:50, 3年前 , 175F
先驗證功能能夠滿足需求滿足價值，再來討論怎樣優化
04/14 07:50, 175F
→
04/14 07:51, 3年前 , 176F
才有意義。 所以重點其實不是程式或方法髒不髒，而是
04/14 07:51, 176F
→
04/14 07:52, 3年前 , 177F
如何盡可能用最小的資源去驗證價值
04/14 07:52, 177F
→
04/14 07:53, 3年前 , 178F
只是用最小資源的情況下"通常"程式或方法會比較髒而已
04/14 07:53, 178F
推
04/14 10:08, 3年前 , 179F
推
04/14 10:08, 179F
推
04/14 18:11, 3年前 , 180F
推
04/14 18:11, 180F
→
04/15 09:05, 3年前 , 181F
開發好像很快，結果脆弱的要死，技術債又一堆，越走越慢
04/15 09:05, 181F
推
04/15 17:34, 3年前 , 182F
這篇好！原原po不爽就噓略失風度，小小格局有限。
04/15 17:34, 182F
‣ 更多 stillboy 的文章
文章代碼(AID): #1WSLwuz6 (Soft_Job)
討論串 (同標題文章)
以下文章回應了本文：
完整討論串 (本文為第 5 之 16 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共16篇)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 stillboy 的文章
文章代碼(AID): #1WSLwuz6 (Soft_Job)