前情提要
會寫這篇文章，是因為最近在 Line 的開發者社群看到一段關於「手刻畫面 vs 使用套件」的討論。
先說明這篇不是在辯論技術優劣，而是在談「原則怎麼被團隊共同定義」，只要團隊有清楚共識，能被維護、能支撐產品成長，我認為就是當下最適合的做法。
在那串討論裡，有前輩提到幾個判斷方向： 做出來的東西是否 maintainable、scalable，有沒有考慮到 SOLID、KISS 之類的 principle。這些都是很經典、也是我自己很認同的指標。
而這些討論也讓我回憶起了自己之前實習時的烏龍事件，其實就是沒有搞清楚「團隊的 principle 是什麼」，而這個事件過程其實蠻有趣、也蠻有意義，所以決定寫下來跟大家分享。
當然有任何不同的想法也歡迎回應給我讓我知道～
主要事件
剛開始實習的時候，主管給我一個 landing page 讓我自己開發。
我當時選了 Chakra UI 作為 UI 框架來開發，同時另一條支線並行的是公司恰巧開始建立 design system，而 MUI 則在與 Chakra UI 的競爭中勝出成為公司的主要 UI library。
我負責的 landing page 也在這時候完成了，上線過程都很順利，結束後設計師來問我：「這個 Input 的樣式我很喜歡，你是用哪個 variant ？」
於是我就把 Chakra UI 的文件傳給他，跟他說我用的是哪一個 Input ，結果他整個大驚失色，因為公司專案其實已經都統一用 MUI 了。
當下我其實沒有太理解到這個技術選型帶來的後續影響，因為以我的理解，MUI 跟 Chakra UI 對工程師來說都算是 maintainable、scalable 的 UI library，開發起來其實不會有太大的差別。
但對設計、其他工程師、甚至客戶來說就不一樣了：
- 設計師沒辦法直接把這個 Input 當成公司共用設計系統的一部分
- 其他工程師打開專案看到 Chakra UI 也不能直接複用到他們的 MUI 專案
- 如果客戶之後說「其他系統的 Input 也要長這樣」，那原本使用 MUI 的系統就會面臨兩難的情況
原則不是抽象教條，而是團隊在當下共同約定的最佳實踐。
也是從這次之後我才真正明白什麼是專案/團隊的原則，很多東西在技術層面看起來都 maintainable / scalable，但放到一個有設計、有 PM、有不同協作者的團隊裡時，最佳實踐就不會是通用的，而是要看這個團隊、這個產品線在當下共同約定好的做法。
我認為當所有協作者腦海中都對這個產品的最佳實踐有輪廓時，這時大家的行為也就會自然收斂成這個專案的設計準則，抑或是這個團隊的設計準則，到那個時候，我們才算是真的有了自己的「系統原則」。
而在這個故事之後，我想延伸分享一個主題。
工程師是建立這個設計準則的重要橋樑
這個標題可能有點主觀，但卻是我這幾年越來越堅定的想法。
剛剛前面說到「團隊的原則」「共用的設計準則」，那麼到底是誰有責任把這些原則說清楚、維持下去 ？
在我看來大部分情況下，工程師寫的程式就像是飛機的黑盒子（Flight Recorder），除了工程師之外，對設計師、PM、老闆、客戶、主管等等相關的 stakeholder 來說，他們無從得知我們到底在程式裡面寫了什麼，唯一的了解方式就是透過我們去解密這個黑盒子，然後轉成自然語言告訴他們。
所以我認為理想的狀態，不是等到「系統出事」或「需求卡死」的時候，大家被迫去拆黑盒子，才發現裡面有一堆沒講清楚的決策。
而是平常就讓相關的人大致清楚：
- 我們現在做到什麼程度 ？
- 這個決策對未來有哪些 trade-off ？
- 這樣做是因為什麼原則在背後支撐 ？
但這一步，也是我覺得最重要、同時也最困難的地方。
為什麼會這麼說呢 ？ 因為我這裡說的「讓他們清楚現在是什麼情況」，不是把所有行為完整回報一遍。
而是要像個行家一樣，幫他們篩選之後，只給他們需要知道的資訊。
我剛開始工作時，最常犯的錯就是這一點： 把自己做的每件事，用條列式全部列出來回報，就像列印一個 5 頁但只有最後一頁有內容的 PDF，一樣要吐出 5 張紙。
對於那個只需要關注「最後結果」的人來說，不只要等前四張「沒內容的紙」印完，還要花時間把多餘的紙歸位。這樣的溝通方式，對雙方來說都是事倍功半。
真正有價值的溝通，不在於資訊量有多大，而在於你有沒有幫對方做好整理、篩選與翻譯，讓他們可以用最少的心智成本，接收最多的關鍵內容。
而這件事，剛好就是工程師最有條件也最該做好的，這點我也仍然還在學習當中。
自己一個人可以走的很快，但是不一定能走的很遠
所以我認為，在現在這個時代，工程師最重要的工作，已經不再只是像以前一樣，成為機器，重複性地生產程式碼。
我們需要花越來越多的時間，去思考「程式碼以外的事情」。
產品需求有 PM 可以跟我們一起釐清，但「工程師的黑盒子」只有工程師自己打得開。
如果想成為一個頂尖的工程師，我認為「幫助團隊溝通、讓大家對系統有共同的理解」這一塊，絕對是非常值得投資的能力。
當一個團隊能夠：
- 在技術選型上有清楚的原則
- 在跨角色之間有順暢的溝通
- 在產品演進時維持一致的設計準則
整體就能更穩定地一起往前走。
隱藏細節也是我認為的重要溝通技巧之一，不只是對內，也是對外，正確的篩選必要資訊，隱藏不必要的繁枝細節。