最近做的一些事情

這段時間在項目中實踐了fastbin和相關的開發思路，覺得有必要寫一篇文章重新跟大家實踐下來的一些經驗，對之前分享內容做個補充。

首先需要梳理一下年初到現在我在開發流程上的幾個觀念改變：

1. 盡量不要使用DSL，DSL的問題是功能和特性隱含在語法中，需要熟記語法並提供完善的文檔才能用起來，無形之中就增加了開發者的心智負擔。其次是DSL從編碼到輸出結果通常不是線性的，無法增量開發也無法即時調試，一些開發工具可以用可視化界面替代掉DSL。

2. 功能模塊應該盡量內聚，項目以功能模塊的視角來組織，這樣可以在開發的時候少一些目錄跳轉和搜尋文件的動作，可以讓開發過程更流暢。

基於以上思路轉變，我製作了fastbin這個工具的原型，並結合到了項目中。

實踐下來發現有幾個問題：

1. fastbin自身代碼太複雜，當加完客戶端代碼生成所需的邏輯之後，發現整個工具很難再擴展和修改。

2. fastbin和link配合使用的時候很不順暢，結合部分的代碼彎彎繞繞的。

fastbin代碼複雜的主要原因是基於AST的類型分析太過複雜，如果是用反射的方式獲取類型信息代碼會少很多，並且靈活性也會高很多。

fastbin和link結合不暢主要在於兩者都定位成了通用的模塊，結合起來的時候沒辦法獲得最佳的體驗。

所以我們重新寫了一遍代碼，做了一個面向服務介面的link，直接內置了分包和消息類型識別，fastbin則作為消息的序列化格式插件，並用反射進行類型分析。

但是反射不能獲得類型上的注釋信息，要生成fastbin的介面協議文檔的時候需要這部分信息。所以生成fastbin的介面協議文檔用的還是AST上的信息。

基於前面說的開發流程理念，我們對之前做的功能模塊配置方式也做了調整，之前我們試過用PHP來做客戶端和服務端共用配置的管理，後來還試了JSON，但這些都不夠直接，主要的問題是配置文件中需要先聲明一遍結構和數據，在服務端又需要再聲明一遍對應的結構才能把數據載入進來。

我們延續fastbin的思路，做了一個配置工具，用go結構體定義配置的結構，並用全局變數的方式原地聲明默認數據，然後再用類型信息和默認數據序列化出JSON配置文件，這樣結構和數據就都在一個文檔里了。

新的代碼暫時不會提交github，等實際驗證過沒有大問題了再跟大家分享。

推薦閱讀：