※ 引述《del680202 (HANA)》之銘言：
: ※ 引述《neo5277 (I am an agent of chaos)》之銘言：
: : 純粹對工作上來說
: : 好抽換，好接手(易閱讀)，好維護(包含升級，測試
: 好接手，易閱讀…
: 我想到一個故事
看到你的故事，讓我想起好多當年犯過的錯誤
: 幾年前有個同事，號稱國中時期就開始接案寫代碼
: clean code,DDD滾瓜爛熟,對coding極度潔癖
: 印象比較深的是入職時說了句：我看到不規範的代碼會非常生氣
我年輕的時候也這樣，但做久了慢慢可以理解凡事都是 trade-off
寫得很漂亮，卻沒商業價值的 code，根本沒人在用，
對比寫得很亂，卻實際有大量使用者的 code，很難說哪個是比較好的。
剛進業界第一份工作，很認真的幫每個 function 寫滿註解跟 API doc，
努力遵循各種 best practice，幾個月後專案取消了，這 code 從來沒上 production
對比那些可怕的 legacy code，每天都好好的運行著賺錢的服務。
後來開始懂得要考量 business 的需求，有時候犧牲一點品質，搶占先機是必要之惡
: 上工第一案子，設計一個工具網站，拆了七個GitHub repo
這我當年剛學 git/github 也做過，把個巨大專案拆了十幾個 repo，
原先要解決的問題是，希望每個元件可以降低耦合，容易獨立使用，分開 deploy。
隨著時間，逐漸發現各個元件需要共用的東西越來越多，互相 dependency 逐漸變多
這時候各個元件之間需要正確的版本，才能互相搭配，管理起來卻成了噩夢
有些直接 include 就能用的東西，拆在兩個 repo 掛 submodule 變得很難維護
build rules / makefile 也因此複雜了起來，最後有點後悔一開始把他們拆開。
體驗過就能理解為何很多大公司最後走向 monorepo 架構，全公司專案都在一個 repo
其中一個經典案例就是 google，幾乎全公司所有 code 在一個巨無霸 repo 內。
不同程式互相引用，就少有版本管理問題，開發的複雜度降低很多。
: Micro services, grpc當年流行的工具全套了一輪
: 說是將低耦合，高內聚做到極致
剛進業界的時候，我也是剛學了 microservice，很開心地把手上系統全拆了
拆分得很乾淨，每個服務都可以分開擴展，一開始還覺得這是 best practice
後來學到血淚教訓。因為業務的改變，需求大幅度改變了。原先的拆分並不合適
反而讓開發、測試、跟部署變得複雜，印證了 "monolith first" 的建議!
在早期需求還不明朗的時候，全部塞在一起，其實不是壞事，延遲到真正出現擴展需求
再來拆分，會比過早拆分要好。這跟不要 premature optimization 感覺很像。
就跟一開始學 OOP 都狂寫 interface，後來才發現根本沒有其他 implementation
白白多了一堆無謂的繼承，最後又發現需要不同的行為，於是換了 interface
本來定義的抽象化不但沒用到，還因為要保持相容，造成日後擴充的阻礙。
後來就學到 "concrete first"，不要起手式就急著開 abstract interface，
可以延後到真的有需要再來做，有時候反而會更合適。
做久了慢慢對這些東西有不同的感受，best practice 通常要放在特定情境下才是 best
如果很清楚自己做了什麼 trade-off，違反它們不見得是錯誤的。
: 其中一個repo 甚至只放了一個utils
: 後來來了另一個人接手
: 改個功能要先看懂七個repo之間關聯，跟找大秘寶似的
: 在review code階段，還埋個彩蛋，發現了隱藏的第八個repo
: 新來的同事說改不動了，就算加個menu都很麻煩
: 心一橫，提案該網站功能也不複雜，全部打掉重做
: 就自己埋頭花了兩週重做了那個網站加遷移
兩個禮拜是不是沒算到寫 test 跟重作 QA 的時間 XD
寫 code 相對快，大部分開發時間本就都花在其他地方
這種大霹靂式的重寫，通常是很危險的 XD
: 工程師追求的很簡單，(自己）好閱讀，（自己）好維護就行了
:

簡單一句話: 不要過早完美化。技術服務業務，隨服務演進

PCMAN大神

只能推

on demand做 而refactor的時候需要test避免你改錯That's why unit tests are important

確實

感謝大大分享

寫不寫的漂亮與市場反應是兩件事情 這與公司經營和高層思想才有關係 寫的好不代表一定花時間但為了不讓資本囂張 我讚同有時可以這麼做

我認為 一個專案的基礎架構 開發藍圖 工時 要能準確估算跟執行真的都需要高度經驗工作而言 重要的事是怎麼在日期限制內交出及格的作品什麼要取捨 什麼一定要做到

有時也不一定是資本囂張 是高層囂張

推這篇，句句是實務

至少你走過來了，辛苦了

推大神

上古神獸推推

推，雖然層級有差但魯蛇做久了感想完全一樣

感謝分享 看完覺得茅塞頓開

最近也有這種感覺，會開始要求自己做到best practice，但老實說這是必經之路吧，經歷過凡事都要求完美的路，才會知道哪些可以放棄不用

大神推推 都是血和淚的教訓

推

best 根本就不存在，完全是商業手法的誤導，欺騙初學者以為只要看到 best 學就對，自己就會變成 best這個世界只有 suitable practice ，最合適的，沒有最好的

很多都這樣 一開始能動最重要，真的有閒穩定下來後才是重構的部分

神獸來了快拜一下~~~interface 還是看語言跟框架用啊

推這篇，這幾年工作下來的經驗也是如此，尤其碰到專案需求變動快速的時候，這篇的經驗會更實用

interface 跟 DDD 就是互相成就遵從到後來都魔怔了，一堆過度設計的場景

先存活下來再想著如何變好但活太久改不動就又是另外一回事了QQ

推這篇~很有同感+1

推

推推

認真分享，給推！

那些指導的書看一本就好, 程式寫多了就有自己的體會再看那些書也有不同的體驗

神出沒

謝謝前輩分享

神來了，必須蓋樓推!

trade-off

大神要拜一下 感謝分享

顯靈

只能推了

大神出沒，推一個！

推

推推

居然是PCMAN，給推

推

推，好奇問，那如果是為了 UT 而弄的 interface 呢?

PCMAN!!!!!!!!!!!!!!!!!

推

其實最主要的問題在於 工程師都很自閉的自己搞東搞西像這些經歷 是不是當初在拼了命分拆小模組前 召集團隊所有人開個會蕉流蕉流 應該就有資深的會跟你說 確定要這樣嗎

資深不代表有決定權 end

設計本來就沒有聖杯 大家吵架出來的就是最佳解 至少團隊裡的人都方便 這樣就行了 不同團隊有不同作法但工程師喔 大多都覺得太麻煩了 太無聊了 沒空 別煩我 你說的我都不同意 我覺得XXXOOO就是最棒的 是尼不懂 哈不過就算亂寫一通其實也沒差啦 聽說OpenAI裡也全都亂寫哪有時間code review吵架 東西先上先贏R 搶快比什麼都重要

推推推

可是吵架很累餒我水瓶，我愛好和平有吵架以外的方法嗎？

有 那就是長官或資深說怎麼做 你就怎麼做

好吧！那看狀況吵好了

大神推

桑原老師說過 架是要兩個人才能吵的

推

PCMan推一個

推大神

Google用內部工具Blaze直接否決高耦合 才能不吵架

那基本上就算是長官或資深說你要怎麼做 你就得怎麼做XD

深有同感

推神獸

推

oop重點寫介面做啥？會寫的直接上手

看需求吧 有場景是要把code喂給編譯器看那就另當別論

推

該怎麼切沒有個聖杯，但核心就是要為爽跟快爽 = 好維護好追問題，快 = 開發不會相依性一堆綁手腳蝦拆但是會往反方向前進的，就是吵 = =

推

有時候寫interface是怕把依賴方向搞爛 有建議嗎

大神推推

推推

好猛

推

謝 strlen，gino0717，TaiwanUp，shortoneal4位大大提供的方向

謝謝大大分享！講的超清楚

朝聖

推

推

推

謝分享

推，這些真的是慢慢工作才會理解到的

推

推

感謝分享

按需求服務 還有漸進式的抽出共用

但c#要mock的話不是一定要interface嗎？ 不測試的話的確是不用interface啦

熱愛嘗試當下流行的新工具新理論的工程師，常常也是團隊主力，很難找到理由阻止他們嘗試新事物

推

好奇Google 那樣要怎麼管理不同套件之間的相依性？ 如果都要保持所有test全過的話 幾乎不太可能推新功能？

推 這如人月神話所說，軟體之中「沒有銀彈」

專業