你好呀，我是歪歪。

我最近其實在思考一個問題：

對于程序員來說，怎樣才算是在寫有“技術含量”的代碼？

為什么會想起思考這個看起來就很厲（裝）害（逼）的問題呢？

因為這就是知乎上的一個問題：

https://www.zhihu.com/question/37093538

第一次看到這個問題的時候，我很快的就劃過去了，完全就沒有關注這個問題。但是就是看了那么一眼，這個問題就偶爾不經意間在腦海中浮現出來。

然后隔了一段時間，中午刷知乎的時候這個問題又冒出來了。

好巧不巧，也是那天中午，我看到了這樣的一個面試題：

看到這個面試題的第一眼，我就想起了 Dubbo 服務中的一個預熱功能。

在結合知乎這個問題，我當時就覺得：Dubbo 服務的預熱源碼在我看來就是一個“有技術含量”的代碼呀。

這一塊功能編碼確實一點也不復雜，主要是能體現出編碼的人對于 JVM 和 RPC 方面的“內功”，能夠意識到，由于 JVM 的編譯特點，再加上 Dubbo 在架構中充當著 RPC 框架的角色，所以為了服務最大程度上的穩定，可以在編碼的層面做一定的服務預熱。

但是寫完相關回答之后，從評論區來看，基本上是清一色的吐槽，說我舉得這個例子和問題相悖。

比如我截取點贊最高的兩個評論：

看完這些吐槽之后，我覺得這些吐槽是有道理的，我的例子舉得確實不好，非常的片面。

開始我還不服氣，但是現在我也是真心的覺得“別人說的對”。

為了更好的引出這個話題，我先搬運并擴充一下我當時的回答吧。

順便也算是回答一下剛剛說的那個面試題。

服務預熱

下面這個方法，只有兩行，但是這就是 Dubbo 服務預熱功能的核心代碼：

org.apache.dubbo.rpc.cluster.loadbalance.AbstractLoadBalance#calculateWarmupWeight

看一下這個方法在框架里面調用的地方：

當我們不指定參數的情況下，入參 warmup 和 weight 是有默認值的：

也就是在用默認參數的情況下，上面的方法可以簡化為這樣：

static int calculateWarmupWeight(int uptime) {
    //int ww = (int) ( uptime / ((float) 10 * 60 * 1000 / 100));
    int ww = (int) ( uptime / 6000 );
    return ww < 1 ? 1 : (Math.min(ww, 100));
}

它的入參 uptime 代表服務啟動時間，單位是毫秒。返回參數代表當前服務的權重。

基于這個方法，我先給你搞個圖。

下面這個圖，x 軸是啟動時間，單位是秒，y 軸是對應的權重：

從圖上可以看出，從服務啟動開始，每隔 6 秒權重就會加一，直到 600 秒，即 10 分鐘之后，權重變為 100。

比如當 uptime 為 60 秒時，該方法的返回值為 10。

當 uptime 為 66 秒時，該方法的返回值為 11。

當 uptime 為 120 秒時，該方法的返回值為 20。

以此類推...

600 秒，也就是十分鐘以及超過十分鐘之后，權重均為 100，代表預熱完成。

那么這個權重是干啥用的呢？

這個就得結合著負載均衡來說了。

Dubbo 提供了如下的五種負載均衡策略：

• Random LoadBalance :「加權隨機」策略
• RoundRobin LoadBalance：「加權輪詢」策略
• LeastActive LoadBalance：「最少活躍調用數」策略
• ShortestResponse LoadBalance：「最短響應時間」策略
• ConsistentHash LoadBalance：「一致性 Hash」 策略

除了一致性哈希策略外，其他的四個策略都得用到權重這個參數：

權重，就是用來決定這次請求發送給哪個服務的一個關鍵因素。

我給你畫個示意圖：

A、B、C 三臺服務，A，B 的權重都是 100，C 服務剛剛啟動。

作為一個剛剛啟動的服務，是不適合接受突發流量的，以為運行在服務器上的代碼還沒有經過充分的編譯，主鏈接上的代碼可能還沒有進入編譯器的 C2 階段。

所以按理來說 C 服務需要一個服務預熱的過程，也就是剛剛啟動的前 10 分鐘，應該有逐步接受越來越多的請求這樣的一個過程。

比如最簡單的加權隨機輪詢的負載均衡策略中，關鍵代碼是這樣的：

org.apache.dubbo.rpc.cluster.loadbalance.RandomLoadBalance#doSelect

看不明白沒關系，我再給你畫個圖。

在 C 服務啟動的第 1 分鐘，它的權重是 10：

所以代碼中的 totalWeight=210，因此下面這行代碼就是隨機生成 210 之內的一個數字：

int offset = ThreadLocalRandom.current().nextInt(totalWeight);

在示意圖中有三個服務器，所以 for 循環中的 lenght=3。

weights[] 這個數組是個啥玩意呢？

看一眼代碼：

每次循環的時候把每個服務器的權重匯總起來，放到 weights[] 里面。

在上面的例子中也就是這樣的：

• weights[0]= 100（A服務器的權重）
• weights[1]= 100（A服務器的權重）+100（B服務器的權重）=200
• weights[2]= 100（A服務器的權重）+100（B服務器的權重）+10（C服務器的權重）=210

當隨機數 offset 在 0-100 之間，A 服務器處理本次請求。在 100-200 之間 B 服務器處理本次請求。在 200-210 之間 C 服務器處理本次請求：

也就是說：C 服務器有一定的概率被選上，來處理這一次請求，但是概率不大。

怎么概率才能大呢？

權重要大。

權重怎么才大呢？

啟動時間長了，權重也隨之增大了。

比如服務啟動 8 分鐘之后，就變成這樣了，C 服務器被選中的概率就大了很多：

最后到 10 分鐘之后，三臺服務器的權重一致，承擔的流量也就幾乎一致了。

C 服務器承擔的請求隨著服務啟動時間越來越多，直到 10 分鐘后到達一個峰值，這就算是經歷了一個預熱的過程。

前面介紹的就是一個預熱的手段，而類似于這樣的預熱思想你在其他的一些網關類的開源項目中也能找到類似的源碼。

但是預熱不只是有這樣的一個實現方式。

比如阿里基于 OpenJDK 搞了一個 Alibaba Dragonwell，其實也就是一個 JDK。

https://github.com/alibaba/dragonwell8

其中之一的特性就是預熱：

除了預熱這個點之外，我還在知乎的回答中提到了最少活躍數負載均衡策略的實現 LeastActiveLoadBalance.java：

從初始化提交之后，一共就沒修改過幾次。

你也可以對比一下，初始版本和當前最新的版本，核心算法、核心邏輯基本沒有發生變化：

除了這個策略之外，其他的幾個策略也是差不多類似的“穩定”。

從評論說起

我在知乎回答這個問題的時候，沒有上面這一小節寫的那么多，但是核心內容大概就是上面這些。

在回答說提到預熱，我是想表達看似不起眼的兩行代碼，背后還是蘊含了非常多的深層次的原因，我覺得這是有“技術含量”的。

而提到負載均衡策略的實現，多年來都沒有怎么變化，我是想表達這些重要的、底層的、基礎的代碼，寫好之后，長年沒動，說明最開始寫出來的代碼是非常穩定的。能寫出這樣穩定的代碼，我覺得這也是有“技術含量”的。

接著帶你看看評論區：

評論幾乎是清一色的不認可這個回答。但是我前面說了，在回答這個問題的時候，確實覺得我的回答是比較貼近主題的。

但是看了評論之后我想明白了，為什么這是一個不好的答案，正如評論區說的：

例子舉得不行，只不過是因為要解決的問題一直沒有發生改變，所以解決方案也就相對穩定。

首先這樣的代碼本來就和絕大部分程序員實際工作中寫的代碼差距過大，框架的源碼值得學習，但是在實際開發中的借鑒意義不大。

而且評論區也提到了，絕大多數程序員根本就沒有機會去寫這樣的比較考驗“技術能力”的代碼。

這也確實是事實，少部分中間件的開發和絕大部分業務邏輯的開發，是兩個思維模式完全不一樣的程序員群體。

然后我看了一下這個話題下的高贊回答：

其實高贊回答就這一句話：

一個優秀的程序員，在接到一個要編寫“毀滅地球”的任務的時候，他不會簡單的寫一個destroyEarth()的方法；而是會寫一個destroyPlanet()的方法，將earth作為一個參數傳進去。

這才是比較貼近我們實際工作的一個例子。

就著這個例子，我換個常規一點的需求來說，比如讓你接入一個微信支付的需求：

你可能會這樣去定義一個類：

public class WechatPayService {
    
    public void wechatPayment(){
        //微信支付相關邏輯
    }
}

當要使用的時候，就把 WechatPayService 注入到需要使用的地方，沒有任何毛病。

但是隨著而來的一個需求是讓你接入支付寶支付。

你當然是自然而然的搞了一個類似的類：

public class AliPayService {
    
    public void aliPayment(){
        //支付寶支付相關邏輯
    }
}

但是你寫著寫著發現：誒，怎么回事，感覺支付寶的這套邏輯和微信的有很多相似之處啊，開發的關鍵步驟感覺都一模一樣？

于是你定義了一個接口，使用策略模式來專門干“支付”相關需求：

public interface IPayService {

    /**
     * 支付抽象接口
     */
    public void pay();
}

在我看來，這是一個非常常規的開發方案，我甚至在拿到“微信支付”這個需求的時候，我就輕車熟路的知道應該使用策略模式來做這個需求，為了方便以后的開發。

但是，我這個“輕車熟路”也是有一個熟悉的過程的，我也不是一開始，一入行，一工作就知道應該這樣去寫的。

我是在工作之后，看了大量的實際項目里面的代碼，看到項目在用，覺得這樣很實用，項目結構也很清晰，才在其它的類似的需求中，刻意的模仿學習、理解、運用、打磨，慢慢的融入到了自己的編碼習慣中去，由于太過熟悉，我漸漸的認為這是沒有技術含量的東西。

直到后來，有一次我帶著一個實習生做一個項目，項目中有一個排行榜的功能，排行榜需要支持各個維度，前端請求的時候會告訴我當前是需要展示哪個排行榜。

在需求分析、系統設計以及代碼落地階段我都自然而然的想到了前面說到的策略模式。

后來實習的同學看到了這一段邏輯，給我說：這個需求的實現方式真好。如果讓我來寫，我絕對想不出這樣的落地方案。

但是我覺得這就是個常規解決方案而已。

我舉這個例子是想表達的意思就是對于“技術含量”這個東西，每個人，每個階段的理解是截然不同的。

與我而言，站在我現在正在寫這篇文章的時間節點上，我覺得有技術含量的代碼，就是別人看到后愿意使用，愿意模仿，愿意告訴后面來的人：這個東西真不錯，你也可以用一用。

它可以小到一個項目里面的只有寥寥幾行的方法類，也可以大到一套行業內問題的完整的技術解決方案。

除了這個例子外，我還想舉我剛剛參加工作不久，遇到過的另外一個例子。

需求說來也很簡單，就是針對一個表的增刪改查操作，也就是我們常常吐槽的沒有技術含量的 crud。

但是，我當時看到別人提交的代碼時我都震驚了。

比如一個新增操作，所有的邏輯都在一個 controller 里面，沒有所謂的 service 層、dao 層，一把梭直接把 mapper 注入到了 controller 里面，在一個方法里面從數據校驗到數據庫交互全部包圓了。

功能能用嗎？

能用。

但是這樣代碼是有“技術含量”的代碼嗎？

我覺得可以說是毫無技術含量了，用現在的流行語來說，我甚至覺得這是程序員在“擺爛”。

我要基于對于這一段代碼繼續開發新功能，我能做什么呢？

我無能為力，原來的代碼實在不想去動。

我只能保證在這堆“屎山”上，我新寫出來的代碼是干凈的、清晰的，不繼續往里面扔垃圾。

后來我讀了一本書，叫做《代碼整潔之道》，里面有一個規則叫做“童子軍軍規”。

軍規中有一句話是這樣的：讓營地比你來時更干凈。

類比到代碼上其實就是一件很小的事情，比如只是改好一個變量名、拆分一個有點過長的函數、消除一點點重復代碼，清理一個嵌套 if 語句...

這是讓項目代碼隨著時間流逝而越變越好的最簡單的做法，持續改進也是專業性的內在組成部分。

我覺得我對于這一點“規則”落實的還是挺好的，看到一些不是我寫的，但是我覺得可以有更好的寫法時，而且改動起來非常簡單，不影響核心功能的時候，我會主動去改一下。

我能保證的是，這段代碼在經過我之后，我沒有讓它更加混亂。

把一段混亂的代碼，拆分的清晰起來，再后來的人愿意按照你的結構繼續往下寫，或者繼續改進。

你說這是在寫“有技術含量”的代碼嗎？

我覺得不是。

但是，我覺得這應該是在追求寫“有技術含量”的代碼之前，必須要具備的一個能力。而且是比寫出“有技術含量”的代碼更加重要的一個基礎能力。

延伸

以上就是我個人的一點觀點，但是我還想延伸出一些別的東西。

比如在寫文章之前，我也在思否網站上提出了這個問題：

https://segmentfault.com/q/1010000042111980

大家見仁見智，從各個角度給出了不同的回答。

這也再次印證了前面我說的觀點：

對于“技術含量”這個東西，每個人，每個階段的理解是截然不同的。

我把大家給我的回復貼過來，希望能對你也有幫助：

再比如我最近在知乎上看到了這樣的一個視頻：

https://www.zhihu.com/zvideo/1542577108190068737?page=ogv

里面的主人公黃玄，說了這樣的一段話：

這已經是另外一個維度的程序員，對于“什么是有技術含量的代碼”的另外一個維度的解答了。

我遠遠達不到這個高度，但是我喜歡這個回答：

不斷的傳承下去，成為下一代軟件，或者說下一代人類文明的基石。我覺得能夠去參與這樣的東西，對我來說，可能是程序員的一種浪漫。

所以你呢，對于這個問題，你會給出什么樣的答案呢？

好了，那本文的技術部分就到這里啦。