🔧 阿川の電商水電行
軟體專案很少會因為有人不會寫程式碼而失敗。
它們之所以失敗，是因為人們私下意見不合，假設沒有受到質疑，而且直到生產出現問題之前，每個人都「保持一致」。
這是一個關於合作專案的故事，合作過程並不順利，但最終取得了成功。
設定：平行工作，平行宇宙
我們當時正在開發一款採用相當標準架構的產品：
-
前端：React + TypeScript
-
後端：REST API
-
多名工程師並行工作
-
緊迫的截止日期（有趣的那種）
一切看起來都很正常……直到後來改變了。
前端假定了一些後端尚未實現的欄位。
後端重構了響應體，卻沒有意識到前端依賴這些響應體。
類型是存在的－只是不存在於同一個宇宙。
雖然沒有出現足以阻止開發的錯誤，但漏洞總是在後期出現。
最糟糕的那種。那種「為什麼我們沒早點發現？」的警示。
第一次真正的合作時刻（又稱爭論）
在某個時候，有人問了一個危險的問題：
“Why don’t we just define the API first?”這引發了以下事件：
-
一位後端工程師擔心失去彈性
-
一位前端工程師擔心速度變慢
-
另一個人說「我們可以以後再解決」（經典語氣）
我們沒有假裝達成一致，而是爭論了一番。
那件事就是轉折點。
決策：API優先（但要務實）
我們並沒有把「API優先」當作一個流行語。
我們將其採納為合作協議。
我們實際上做了什麼：
-
早期定義了 OpenAPI 規範
-
前端產生的類型
-
將 API 的重大變更視為真正的重大變更，而不是「哎呀」。
我們接受的權衡：
-
後端失去了一些「隨意重命名」的自由
-
規範要求嚴格遵守和審查
-
前期變更所需時間稍長。
我們獲得了什麼：
-
可預測的前端類型
-
減少意外狀況
-
公關評論平靜得多
意想不到的好處：更好的溝通
最大的勝利不在於技術，而在於人性。
而不是：
“Why is this field missing?”我們開始問：
“Should this field even exist?”規格要求迫使我們：
-
明確命名事物
-
爭論責任問題
-
讓決策透明化
設計評審變成了真正的設計評審，而不是事後分析。
我們犯過的錯誤（所以你不要美化這些錯誤）
說實話——過程並不順利：
-
我們一開始就制定了過多的規定，後來又不得不放寬一些。
-
一份宣傳稿比某些小說還長。
-
我們曾經破壞過 API，卻忘記重新產生類型（是的，那很傷人）。
合作並不能消除錯誤。
這只是讓它們更便宜、更早上市而已。
幽默小插曲：「一個小小的改變」的謊言
每個團隊都會經歷這一刻：
“It’s just a small backend change.”臨終遺言。
有了共同的規範，這句話就變成了：
“It’s a small change… but it touches 12 endpoints.”這正是合併前你想要的坦誠。
高層協作的真實面貌是什麼樣的
根據這次經歷，我現在相信：
-
合作正及早發現分歧。
-
沉默比衝突更危險
-
工具並不能解決團隊問題——它們只會暴露團隊的問題。
-
明確的合約可以減少受個人私利驅動的決策。
資深工程師不會避免摩擦。
他們管理得井井有條。
最終結論
良好的合作並非只是表現得友善。
關鍵在於坦誠相待，偶爾也要克服一些不適──但要攜手共進。
當團隊今天不再追求速度，而是開始追求信任時，程式碼庫也會跟著改變。
是的——有時候事情就是從爭吵開始的。
原文出處：https://dev.to/art_light/we-didnt-align-we-argued-and-shipped-a-better-system-1818
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
