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