轉載/技術瑣話 ，作者老G先生
不要問我為啥總關注脈脈，因為脈脈裡有真話。今天的話題是：為啥大廠熱衷於造輪子？
脈脈上討論造輪子的事情太多了，隨便截幾個圖看看。
其實不只是大廠，中型公司亦有不少造輪子的，俗話說人上一百形形色色。造輪子的原因大抵總結下面幾類。
1、別人的輪子不好用
開源產品不少輪子已經齊備，但是往往存在滿足80%-90%的需求的情況，為了10%造一個輪子，也大有人在。
2、為了彰顯技術實力，好晉升
自己造的總是最好的。
3、真不是想造，你的需求優先順序太低
一些中臺團隊，把服務使用者分了一環二環N環，當你的需求處於三環外，你咋辦？ 指望不上，只能自己造唄。
4、透過造輪子，提升技術實力。
這年頭跟人聊業務系統，水深水淺不好聊。聊聊JVM調優，RPC/message/分散式排程這些來上一套，也可以稱之“統一溝通語言”，面試者和麵試官皆大歡喜。
造輪子有沒有好處？
要老G說，還真有。
畢竟業務為王，為了滿足業務，要想盡一切辦法解決問題。如果沒有可用的輪子，自己可以改一個。當年dubbo沒有維護了， 噹噹也折騰了dubbox。你依賴的工具/平臺團隊不接你的需求，這事還得自己造。
如何調優一家公司的諸多“輪子”？看起來是創新，可能是“閉門造破車”！ 老G認為，有幾個方向可以考慮。
1、還是在公司層面確定組織和業務的服務關係。
該Top-Down解決的問題，別讓下面的小同學在那裡搶地盤瞎折騰。比如某廠社交事業部和電商事業部，RPC框架/訊息/日誌/排程任務管理等等是否需要統一？ 不需要也行，集團公司考核的是最終事業部的營收情況，你把精力更多放在做基礎輪子上，做業務服務的人力就少了。當然這考驗領導層的管理能力，花多少錢辦事，是否是承包責任制，人//財/物/業算總賬。
如果有中臺團隊來做基礎中介軟體的功能，也明確對該團隊的考核。社交事業部和電商事業部的需求，你都該滿足。別區分親疏，KPI 對齊了，讓下面的人做事刷臉。
2、在事業部內部，拉通晉升條線的評選。
小部門A的事情，有業務結果，業務方埋單；小部門B的事情，有業務結果，業務方埋單；如果A和B 做的領域就是重複的造輪子，需要一個視窗看見，需要被考核，鼓勵什麼，反對什麼。比如在某些公司，如果說不清楚做的平臺，和公司內其他幾個平臺的關係，就不能晉升到某一層級。
3、正向鼓勵合作。據說微軟員工的收入與impact相關。
impact強調合作，在跟老闆review的時候也要寫自己跟哪些團隊合作拿到哪些結果，透過合作團隊拿到的業績越多，績效考核越高。從而避免內卷。
4、取決於技術帶頭人的見識。俗話說上有所好，下必趨之。
網易汪源老師感嘆說，如果DDB這款產品早開源，就沒有ShardingSphere什麼事情了。別人開源的好東西，你今天看著不爽，自己造的可能2年就沒人維護了。但是開源的還有無數人在增加新特性和修復bug，這就是open的力量。技術帶頭人要判斷，什麼東西應該站在巨人的肩膀上，什麼東西應該保持自己的獨創性，而什麼東西應該分享出去，具有更強的生命力。
今天的某些輪子很紅火，可能是歷史長河的一粒沙。
今天你笑別人的程式碼low，可能後人哀之而不鑑之，亦使後人復哀後人矣。
造輪子，不得不慎，與大家勉。
既然來了，就點個關注吧，更多那些年資料分析的事兒聽我給你慢慢道來。
