軟件領域的Reinvent

蘋果經常喜歡用“Reinvent”這個詞，用在硬件領域確實高大上。但在軟件領域Reinvent大多時候是個貶義詞，軟件領域上下游結合及 相互依賴非常緊密，沒有哪個團隊甚至公司能封閉的完成所有事情。因此重新發明這件事情在軟件領域并不吃香，一個新的體系在小的團隊通常會自生自滅（盡管途 中可以獲得一些榮譽），剩下那些硬撐的項目則會讓參與人員痛苦不堪。

比如各廠定制的各種百花齊放的框架，運作幾年之后，核心系統越來越臃腫，隨著人員的更替能深入了解內部的人也越來越少，改進的動作非常遲鈍。但 大量的上下游業務服務又需要依賴這些系統，新來的人需要較高的成本熟悉整套系統。問題叢生，但是離開又需要付出極大代價，于是就成了一個雞肋。如果使用方 牽涉到多個部門，更不會有人站起來說將這些定制系統廢棄或遷移。

但這個現象在計算機語言領域則是一個例外。一門新的語言，不喜歡的人可以不用，而且大部分開發團隊是隨大流，不會選用小眾語言，所以新語言領域 已經在搭建的哪些不成熟的系統也不會給業界帶來麻煩及痛苦。少量情況下，極客會心愛的小眾語言搭建的一些系統，但根據觀察，這些系統通常會隨著極客的離職 馬上會被用主流語言重寫替換。因此在新語言領域，可以用更輕松的心態去重新發明各種組件。

一門語言出來之后，復用另外一種語言的模塊與組件不是最佳方案，理想情況會選擇構建自己的函數庫，框架，開發工具，測試工具，代碼工具，性能調優工具等。在新的語言出來的早期，這些領域一片空白，踏入這片領域的人會有新大陸淘金的感覺，隨便寫點東西，很快可以找到市場。

在一個新的語言重寫一些別的語言已經完成的項目，盡管這不是什么偉大的發明創造，但參與的人往往更快的取得了成績并且贏得了尊敬（相對于在“主 流”語言拼搏那些人）。我也曾經思考過這個現象。技術人的價值觀雖然很多元化，但是有兩點卻幾乎是共通的，一是工程師動手創造帶來的成就感，二是感受創造 的東西給所在環境以及業界帶來使用價值的成就感，不管這些創造是原創的還是山寨。因此在很多領域如搜索、廣告以及更基礎層面OS、Database、 Language總是有樂此不疲工程師重新去建設，因此在語言層面的重新建設就變得容易理解了。

更深層次的來看，在語言層面的基礎上，重新去構建一個生態圈，從社區的角度，不只是重新克隆一個新的版本，工程師會考慮以往的經驗及教訓，重新 設計重要的單元，以帶來性能上的提升及使用方式上的改進。比如這幾天寫一個Go語言的小程序，看到Go的社區在配置文件方面的思考及重新選擇。配置管理在 Java領域大多是XML一統天下，盡管其可維護性較差，但由于歷史原因，工程師很難去領取爐灶。

當然在新OS領域重新創造的機會就更多，但是這種情況較少發生，一個新的OS生命周期會延續10年或更久。一些大公司的開發平臺生態圈也有類似的這樣的機會，不過大部分情況下格局會小很多，也會存在更大的不確定性。