現在還能記得C++11標準釋出前我在琢磨右值引用的語義和各種神奇“副作用”的時候。
某種意義上我算是正經用過的語言比較多，且對各種語法細節記憶相對較好的人。所以對於C++這種NB的人可以用的很NB的語言，每逢新版本釋出的時候，必然是頗為關心的。
但時至今日，面對C++20這樣的大版本更新，我已經沒有太多鑽研的興趣。之前還會冷不丁的對某些或大眾或小眾的語言提起興趣，但確實頻率是在逐漸降低的。
最近學新語言的時候雖然還會較為仔細的研究語法細節，但更多的已經不是關注這個特性很煊很NB，而是【這麼設計明顯是在給新人挖坑啊】、【設計這個的人真的有為軟體工程實踐考慮麼】……
當然，我也追求好的工具，併為好的工具興奮。但體驗了足夠的場景之後，我已經認識到（目前已有的）語言本身還不足以（單獨）成為一個足夠強力的工具。
生態圈、大批次的熟練使用者、足夠的開發效率都是必要的。單純更換一個更好的語言，重寫整個生態圈的所有主要基礎設施，以及能跟現有各種C ABI的庫互動，雖然這些很重要，很好很NB，但在所有領域翻盤已經是不可能的了。Rust我說的就是你，不過雖然這麼說，我還是會在將來有機會的時候上手一下的。
顛覆性的特性
很多時候現在已有的語言已經足夠用了，無論是高效能、高可靠還是方便靈活。
但還有至少2個問題：
下面分別談下。
1複雜業務邏輯
目前制約著網際網路技術發展，甚至是所有PC端、服務端、移動端、Web端的一個問題是複雜邏輯的正確開發和維護成本太高。究其本質原因，是因為人本身是會犯錯的動物、腦容量也有限，類似於1道題99%能答對，100道題就至少有63%的機率會犯至少一個錯誤，但bug的排查成本卻不是線性增長。
這個問題我早在上學時候就從《人月神話》中看到了，但時至今日，這本書出了40多年以後，我們仍然被這個問題困擾，甚至很多時候我目睹的陷入這個焦油坑的專案參與者甚至都不知道這是一種現象，而不是他們的隊友是白痴。
為了降低同事的理解難度，我經常要先用邏輯層面先表述一下業務邏輯，然後再讓他們把這個邏輯層面的流程轉化為一個具體的工程實現。在這個過程中我看到了大量相對於業務邏輯的冗餘程式碼（異常處理不算冗餘），例如我們經常要在不同的結構和介面之間把同樣的一些欄位複製來複制去，這次多3個，下次少傳5個，一會穿過資料庫，一會還要傳給前端。而各種複雜的場景和業務邏輯流程中的埋點，日誌進入hive，BI再用SQL從hive中還原各種複雜的流程中犯錯的機率更是令人絕望。
我認為需要一種更高的表達方式來直接表述邏輯流程，具體的各語言實現、跨語言的適配、與資料庫的互動、以及各種工程和業務監控、聚合報表等，都需要一個大統一的平臺來實現。這似乎很像PM會說的話，我只想要實現這個功能，並能隨時跟蹤資料，而不是這些程式碼和bug。
但時至今日，我並沒有看到一個足夠好（60分）的方案。
甚至就算是複雜業務流程的資料表示方式都還沒有看到。SQL能處理的層面也只是在二維表的層面：我只是想給每條記錄追加一個欄位，為什麼需要寫一個這麼複雜的join？我只是想獲得類別資訊，為什麼需要group by？
2架構設計經驗的固化
在一個分散式、多服務、高可用的系統設計中，有很多經驗其實並不複雜，也並不玄學，可靠性也是看你是否有足夠的經驗能想到各種問題的情況。
某種意義上，一個靠譜的（80分）架構師的培養還是有方可循的，只是沒有那麼錢讓他去親自操刀一下各種型別的專案。
除了少數極端場景，剩下架構師基本沒有特費困難的地方，他面對主要問題是：
歸根結底就是兩條：
看到這裡大家能想到什麼呢？
我們需要一個全系統程式碼生成器，輸入一套業務流程，然後自動生成全套的各端系統程式碼，包括資料庫定義和互操作。
其實這並沒有那麼難，就算是要追求一個比較優的設計，也可以透過全系統壓測profile來自動選擇最優的方案。反而是在業務還沒有的時候如何“正確”構造壓測資料的挑戰更大。
當我們追求全鏈路的事務性，或者極高可靠性的時候，其實機器推導和證明遠比人有優勢，畢竟人腦容量有限。讓一組架構師在合理的時間裡想明白300種互不相似的情況的系統怎麼做最優設計基本是不太可能的。
特別是當作業務流程線上升級的時候，自動化的方式就更能顯現。
2.1順便談下業務邏輯變更
人工一般只做少數簡單升級情況，因為這個一般不算在專案開發成本之中，升級過程導致資料被破壞簡直已經不是新聞。
所以大家一般都是選業務全停的凌晨，或是以某種形式阻斷請求，來簡化升級程式需要處理的情況。但這些操作一般都是比較粗粒度的，因為設計升級流程的人的精力往往不足以處理這個問題。
自動程式碼生成的方案可以根據兩個版本的業務流程自動生成一套升級方案，只需要人工填入關鍵部分的對映方式，對於不好處理的狀態可以選擇人工選擇阻斷某些型別的情況，來簡化輸入。
即使是需要之前方案自動最佳化掉沒有落地的資料，也可以透過引入一箇中間階段的方案來實現：
由於埋點和資料統計也是由此全系統程式碼生成器實現，所以只要正確指定了新舊業務之間的監控指標對映方式就可以實現統計資料無影響。
在關鍵的服務中，需要線上實時升級的業務一般都是手工做上述3步，其中中間版本經常還是不算在總升級時間中的，提前重構完成。穩健升級模式下，全流程經常搞1個月已經很快了，搞一個季度我都不奇怪。
這樣，一般性的架構設計經驗都可以沉澱在這個架構生成器上。
現在還能記得C++11標準釋出前我在琢磨右值引用的語義和各種神奇“副作用”的時候。
某種意義上我算是正經用過的語言比較多，且對各種語法細節記憶相對較好的人。所以對於C++這種NB的人可以用的很NB的語言，每逢新版本釋出的時候，必然是頗為關心的。
但時至今日，面對C++20這樣的大版本更新，我已經沒有太多鑽研的興趣。之前還會冷不丁的對某些或大眾或小眾的語言提起興趣，但確實頻率是在逐漸降低的。
最近學新語言的時候雖然還會較為仔細的研究語法細節，但更多的已經不是關注這個特性很煊很NB，而是【這麼設計明顯是在給新人挖坑啊】、【設計這個的人真的有為軟體工程實踐考慮麼】……
當然，我也追求好的工具，併為好的工具興奮。但體驗了足夠的場景之後，我已經認識到（目前已有的）語言本身還不足以（單獨）成為一個足夠強力的工具。
生態圈、大批次的熟練使用者、足夠的開發效率都是必要的。單純更換一個更好的語言，重寫整個生態圈的所有主要基礎設施，以及能跟現有各種C ABI的庫互動，雖然這些很重要，很好很NB，但在所有領域翻盤已經是不可能的了。Rust我說的就是你，不過雖然這麼說，我還是會在將來有機會的時候上手一下的。
顛覆性的特性
很多時候現在已有的語言已經足夠用了，無論是高效能、高可靠還是方便靈活。
但還有至少2個問題：
複雜的業務邏輯及其資料描述和持久化。將架構設計經驗固化為“程式”。下面分別談下。
1複雜業務邏輯
目前制約著網際網路技術發展，甚至是所有PC端、服務端、移動端、Web端的一個問題是複雜邏輯的正確開發和維護成本太高。究其本質原因，是因為人本身是會犯錯的動物、腦容量也有限，類似於1道題99%能答對，100道題就至少有63%的機率會犯至少一個錯誤，但bug的排查成本卻不是線性增長。
這個問題我早在上學時候就從《人月神話》中看到了，但時至今日，這本書出了40多年以後，我們仍然被這個問題困擾，甚至很多時候我目睹的陷入這個焦油坑的專案參與者甚至都不知道這是一種現象，而不是他們的隊友是白痴。
為了降低同事的理解難度，我經常要先用邏輯層面先表述一下業務邏輯，然後再讓他們把這個邏輯層面的流程轉化為一個具體的工程實現。在這個過程中我看到了大量相對於業務邏輯的冗餘程式碼（異常處理不算冗餘），例如我們經常要在不同的結構和介面之間把同樣的一些欄位複製來複制去，這次多3個，下次少傳5個，一會穿過資料庫，一會還要傳給前端。而各種複雜的場景和業務邏輯流程中的埋點，日誌進入hive，BI再用SQL從hive中還原各種複雜的流程中犯錯的機率更是令人絕望。
我認為需要一種更高的表達方式來直接表述邏輯流程，具體的各語言實現、跨語言的適配、與資料庫的互動、以及各種工程和業務監控、聚合報表等，都需要一個大統一的平臺來實現。這似乎很像PM會說的話，我只想要實現這個功能，並能隨時跟蹤資料，而不是這些程式碼和bug。
但時至今日，我並沒有看到一個足夠好（60分）的方案。
甚至就算是複雜業務流程的資料表示方式都還沒有看到。SQL能處理的層面也只是在二維表的層面：我只是想給每條記錄追加一個欄位，為什麼需要寫一個這麼複雜的join？我只是想獲得類別資訊，為什麼需要group by？
2架構設計經驗的固化
在一個分散式、多服務、高可用的系統設計中，有很多經驗其實並不複雜，也並不玄學，可靠性也是看你是否有足夠的經驗能想到各種問題的情況。
某種意義上，一個靠譜的（80分）架構師的培養還是有方可循的，只是沒有那麼錢讓他去親自操刀一下各種型別的專案。
除了少數極端場景，剩下架構師基本沒有特費困難的地方，他面對主要問題是：
業務方對資料估計不準，得結合自己的判斷，併為判斷錯誤時候留下預案。開發成本太高，基本不允許試錯和返工重來，如何能一次做出一個在各種情況下都能用的方案。業務需求變化很快，PM也沒譜，有一大堆產品idea需要逐個試錯，如何降低總成本。歸根結底就是兩條：
由於資料不足或者試錯導致的頻繁修改開發成本太高看到這裡大家能想到什麼呢？
我們需要一個全系統程式碼生成器，輸入一套業務流程，然後自動生成全套的各端系統程式碼，包括資料庫定義和互操作。
其實這並沒有那麼難，就算是要追求一個比較優的設計，也可以透過全系統壓測profile來自動選擇最優的方案。反而是在業務還沒有的時候如何“正確”構造壓測資料的挑戰更大。
當我們追求全鏈路的事務性，或者極高可靠性的時候，其實機器推導和證明遠比人有優勢，畢竟人腦容量有限。讓一組架構師在合理的時間裡想明白300種互不相似的情況的系統怎麼做最優設計基本是不太可能的。
特別是當作業務流程線上升級的時候，自動化的方式就更能顯現。
2.1順便談下業務邏輯變更
人工一般只做少數簡單升級情況，因為這個一般不算在專案開發成本之中，升級過程導致資料被破壞簡直已經不是新聞。
所以大家一般都是選業務全停的凌晨，或是以某種形式阻斷請求，來簡化升級程式需要處理的情況。但這些操作一般都是比較粗粒度的，因為設計升級流程的人的精力往往不足以處理這個問題。
自動程式碼生成的方案可以根據兩個版本的業務流程自動生成一套升級方案，只需要人工填入關鍵部分的對映方式，對於不好處理的狀態可以選擇人工選擇阻斷某些型別的情況，來簡化輸入。
即使是需要之前方案自動最佳化掉沒有落地的資料，也可以透過引入一箇中間階段的方案來實現：
全系統程式碼生成器，比較兩版業務邏輯，生成一個過度版本，線上功能同舊版，但內部系統狀態儲存方式重構，以滿足切換到新業務邏輯時候的需求。從舊版本線上升級到過渡版本，業務理論上不受影響，方便外界進行迴歸。程式碼生成器根據中間版本和目標版本生成線上遷移程式，然後執行之，所有線上請求要麼完整的被舊邏輯處理，要麼完整的被新邏輯處理。由於埋點和資料統計也是由此全系統程式碼生成器實現，所以只要正確指定了新舊業務之間的監控指標對映方式就可以實現統計資料無影響。
在關鍵的服務中，需要線上實時升級的業務一般都是手工做上述3步，其中中間版本經常還是不算在總升級時間中的，提前重構完成。穩健升級模式下，全流程經常搞1個月已經很快了，搞一個季度我都不奇怪。
這樣，一般性的架構設計經驗都可以沉澱在這個架構生成器上。