→ keke0421: 簡單一句話: 不要過早完美化。技術服務業務，隨服務演進 05/15 16:29
推 oherman: PCMAN大神 05/15 16:39
推 kuosos520: 只能推 05/15 16:44
推 Romulus: on demand做 而refactor的時候需要test避免你改錯 05/15 16:54
→ Romulus: That's why unit tests are important 05/15 16:55
推 NTUTM04: 確實 05/15 17:03
推 jackflu: 感謝大大分享 05/15 17:30
→ superpandal: 寫不寫的漂亮與市場反應是兩件事情 這與公司經營和高 05/15 17:41
→ superpandal: 層思想才有關係 寫的好不代表一定花時間 05/15 17:42
→ superpandal: 但為了不讓資本囂張 我讚同有時可以這麼做 05/15 17:44
→ ybite: 我認為 一個專案的基礎架構 開發藍圖 工時 要能準確估算跟 05/15 17:46
→ ybite: 執行真的都需要高度經驗 05/15 17:46
→ ybite: 工作而言 重要的事是怎麼在日期限制內交出及格的作品 05/15 17:47
→ ybite: 什麼要取捨 什麼一定要做到 05/15 17:47
→ superpandal: 有時也不一定是資本囂張 是高層囂張 05/15 17:47
推 AvatarH: 推這篇，句句是實務 05/15 18:38
推 moon2519: 至少你走過來了，辛苦了 05/15 18:57
推 tomsangotw: 推大神 05/15 19:19
推 blackcan: 上古神獸推推 05/15 20:28
推 genius945: 推，雖然層級有差但魯蛇做久了感想完全一樣 05/15 20:51
推 ko00385331: 感謝分享 看完覺得茅塞頓開 05/15 20:56
推 richardz: 最近也有這種感覺，會開始要求自己做到best practice 05/15 21:09
→ richardz: ，但老實說這是必經之路吧，經歷過凡事都要求完美的路 05/15 21:09
→ richardz: ，才會知道哪些可以放棄不用 05/15 21:09
推 Walkers: 大神推推 都是血和淚的教訓 05/15 21:55
推 whyhsu: 推 05/15 22:08
推 accessdenied: best 根本就不存在，完全是商業手法的誤導，欺騙初 05/15 22:17
→ accessdenied: 學者以為只要看到 best 學就對，自己就會變成 best 05/15 22:17
→ accessdenied: 這個世界只有 suitable practice ，最合適的，沒有 05/15 22:18
→ accessdenied: 最好的 05/15 22:18
推 ikachann: 很多都這樣 一開始能動最重要，真的有閒穩定下來後才是 05/15 22:20
→ ikachann: 重構的部分 05/15 22:20
推 ikachann: interface真的是說到點了，可能補習班教吧 一堆人都照著 05/15 22:22
→ ikachann: 一個service都做一個interface然後就只有自己實作 05/15 22:22
推 neo5277: 神獸來了快拜一下~~~ 05/15 22:41
→ neo5277: interface 還是看語言跟框架用啊 05/15 22:42
推 a90100: 推這篇，這幾年工作下來的經驗也是如此，尤其碰到專案需求 05/15 23:20
→ a90100: 變動快速的時候，這篇的經驗會更實用 05/15 23:20
推 stepnight: interface 跟 DDD 就是互相成就 05/15 23:56
→ stepnight: 遵從到後來都魔怔了，一堆過度設計的場景 05/15 23:56
推 ghost90331: 先存活下來再想著如何變好 05/16 00:00
→ ghost90331: 但活太久改不動就又是另外一回事了QQ 05/16 00:00
推 viper9709: 推這篇~很有同感+1 05/16 00:48
推 TonyQ: 推 05/16 02:00
推 HmmHmm: 推推 05/16 04:54
推 marra: 認真分享，給推！ 05/16 05:38
推 descent: 那些指導的書看一本就好, 程式寫多了就有自己的體會 05/16 08:41
→ descent: 再看那些書也有不同的體驗 05/16 08:42
推 buffon: 神出沒 05/16 08:53
推 yuinami: 謝謝前輩分享 05/16 09:12
推 LINGZ: 神來了，必須蓋樓推! 05/16 09:49
推 realbout: trade-off 05/16 09:56
推 rog43: 大神要拜一下 感謝分享 05/16 10:06
推 oiukjyhntgb: 顯靈 05/16 10:57
推 hobnob: 只能推了 05/16 10:59
推 chyl13579: 大神出沒，推一個！ 05/16 11:25
推 devilkool: 推 05/16 11:33
推 v86861062: 推推 05/16 12:08
推 abc21086999: 居然是PCMAN，給推 05/16 12:37
推 slowwalker: 推 05/16 14:23
推 shibin: 推，好奇問，那如果是為了 UT 而弄的 interface 呢? 05/16 14:39
推 Dix123: PCMAN!!!!!!!!!!!!!!!!! 05/16 15:38
推 kyukyu: 05/16 16:08
推 joewang85: 推 05/16 17:38
推 strlen: 其實最主要的問題在於 工程師都很自閉的自己搞東搞西 05/16 17:55
→ strlen: 像這些經歷 是不是當初在拼了命分拆小模組前 召集團隊所有 05/16 17:56
→ strlen: 人開個會蕉流蕉流 應該就有資深的會跟你說 確定要這樣嗎 05/16 17:57
→ fgh81113: 資深不代表有決定權 end 05/16 18:01
→ strlen: 設計本來就沒有聖杯 大家吵架出來的就是最佳解 至少團隊裡 05/16 18:01
→ strlen: 的人都方便 這樣就行了 不同團隊有不同作法 05/16 18:02
→ strlen: 但工程師喔 大多都覺得太麻煩了 太無聊了 沒空 別煩我 你 05/16 18:02
→ strlen: 說的我都不同意 我覺得XXXOOO就是最棒的 是尼不懂 哈 05/16 18:02
→ strlen: 不過就算亂寫一通其實也沒差啦 聽說OpenAI裡也全都亂寫 05/16 18:05
→ strlen: 哪有時間code review吵架 東西先上先贏R 搶快比什麼都重要 05/16 18:05
推 bartd0037308: 推推推 05/16 18:57
推 lchcoding: 可是吵架很累餒 05/16 19:13
→ lchcoding: 我水瓶，我愛好和平 05/16 19:13
→ lchcoding: 有吵架以外的方法嗎？ 05/16 19:13
→ strlen: 有 那就是長官或資深說怎麼做 你就怎麼做 05/16 19:56
→ lchcoding: 好吧！那看狀況吵好了 05/16 20:07
推 Boska: 大神推 05/16 20:40
推 gino0717: 桑原老師說過 架是要兩個人才能吵的 05/16 20:52
推 seal0112: 推 05/16 21:29
推 johney719: PCMan推一個 05/16 22:24
推 rtoday: 推大神 05/16 22:48
推 TaiwanUp: Google用內部工具Blaze直接否決高耦合 才能不吵架 05/16 23:09
→ strlen: 那基本上就算是長官或資深說你要怎麼做 你就得怎麼做XD 05/17 00:11
推 qoozxc789: 深有同感 05/17 01:14
推 Suleika: 推神獸 05/17 02:25
推 leon1757tw: 推 05/17 02:56
推 prag222: oop重點寫介面做啥？會寫的直接上手 05/17 07:12
