或許是我變強(qiáng)了

前幾天，在股東群里看到一條消息：“感覺這個(gè)代碼注釋不太夠啊”。我默默打開了austin項(xiàng)目，在核心流程上翻了些代碼，自我感覺良好，注釋應(yīng)該是有的才對。

當(dāng)然了，跟下圖這種頂級開源組件，注釋是沒法比的，這種要求確實(shí)很高了，就不亞于在注釋里寫文檔了。

我在初學(xué)的時(shí)候，會寫很詳細(xì)的注釋。說到這，我這去翻下我以前初學(xué)時(shí)的代碼，舉例給你們看看：

工作了幾年以后，看了不少系統(tǒng)，也發(fā)現(xiàn)很多人寫的注釋其實(shí)是沒有意義的，在些無關(guān)緊要的地方寫下注釋，這些注釋看了好像跟沒看一樣：

// 打印日志
log.info("austin");

// 創(chuàng)建Map
Map<String, String> map = new HashMap<>();

// 把List集合所有元素清空
list.clear();

// 把HashSet對象添加至List集合
list.addAll(set);

后來，我習(xí)慣在自認(rèn)為有必要的地方才加上對應(yīng)的注釋。一般是為了講述業(yè)務(wù)邏輯的流程(寫在類或方法上)，亦或是用注釋隔斷代碼塊分割邏輯(寫在方法內(nèi))。

/**
 * 獲取 contentModel，替換模板msgContent中占位符信息
 */
private static ContentModel getContentModelValue(MessageTemplate messageTemplate, MessageParam messageParam) {

    // 得到真正的ContentModel 類型
    Integer sendChannel = messageTemplate.getSendChannel();
    Class<? extends ContentModel> contentModelClass = ChannelType.getChanelModelClassByCode(sendChannel);

    // 得到模板的 msgContent 和 入?yún)?/span>
    Map<String, String> variables = messageParam.getVariables();
    JSONObject jsonObject = JSON.parseObject(messageTemplate.getMsgContent());


    // 通過反射 組裝出 contentModel
    Field[] fields = ReflectUtil.getFields(contentModelClass);
    ContentModel contentModel = ReflectUtil.newInstance(contentModelClass);
    for (Field field : fields) {
        String originValue = jsonObject.getString(field.getName());

        if (StrUtil.isNotBlank(originValue)) {
            String resultValue = ContentHolderUtil.replacePlaceHolder(originValue, variables);
            Object resultObj = JSONUtil.isJsonObj(resultValue) ? JSONUtil.toBean(resultValue, field.getType()) : resultValue;
            ReflectUtil.setFieldValue(contentModel, field, resultObj);
        }
    }

    // 如果 url 字段存在，則在url拼接對應(yīng)的埋點(diǎn)參數(shù)
    String url = (String) ReflectUtil.getFieldValue(contentModel, LINK_NAME);
    if (StrUtil.isNotBlank(url)) {
        String resultUrl = TaskInfoUtils.generateUrl(url, messageTemplate.getId(), messageTemplate.getTemplateType());
        ReflectUtil.setFieldValue(contentModel, LINK_NAME, resultUrl);
    }
    return contentModel;
}

對于總體的系統(tǒng)架構(gòu)或者系統(tǒng)流程，或是覺得有比較難懂的地方，我一般會單獨(dú)寫成文檔。

我寫了幾年博客了，對我比較好的評價(jià)就說我的博客寫得通俗易懂。我翻看自己寫的博客，我也認(rèn)為自己寫得不錯(cuò)。

我在初學(xué)的時(shí)候，看過太多的博客了，那時(shí)候他們寫的內(nèi)容，有好多我都理解不了。后來我理解透了以后，發(fā)現(xiàn)明明就不是復(fù)雜的東西，但是從他們博客上就是看不懂，我很簡單的就能想到：他們根本就不懂初學(xué)者。

所以，后來我大多數(shù)博客都是以初學(xué)者的角度去寫的，按著我學(xué)習(xí)的思考思路和過程，一般寫得也比較詳細(xì)。所以吧，往往我看到通俗易懂的文章了以后，會想，有沒有可能是寫博客的人把這知識講述變簡單了，而不全是自己的理解能力。

工作了幾年以后，我逐漸也偏向省略些基礎(chǔ)內(nèi)容了。

• 覺得這塊以前就寫過了，引用個(gè)文章就算了，但是卻好像沒幾個(gè)人會點(diǎn)擊這個(gè)引用的文章。
• 覺得能看這篇文章的人，應(yīng)該有相關(guān)基礎(chǔ)了，沒必要再重復(fù)講述某個(gè)基礎(chǔ)細(xì)節(jié)了。

如果austin算是沒有什么注釋的話，那去到公司看項(xiàng)目代碼，那就更坑爹了。大多數(shù)開發(fā)真的不太愿意寫文檔，寫注釋，無論大廠還是小廠，很多都一樣的，業(yè)務(wù)和細(xì)節(jié)就是口口相傳。如果你遇到的項(xiàng)目注釋和文檔都很齊全，那你真的是維護(hù)了寶藏系統(tǒng)。

回到項(xiàng)目代碼上，注釋是一方面，另一方面，其實(shí)無論是誰看別人代碼，在最開始看的時(shí)候，都是會感到陌生的。只要有某個(gè)地方卡住了，在代碼里沒看到對應(yīng)的注釋，都不會太好受。但，相信我，這肯定是常態(tài)。

當(dāng)遇到好的代碼，驚嘆下前人的代碼是真不錯(cuò)，看看有沒有可以借鑒參考的地方，用小本本記下來，絕大多數(shù)時(shí)候自己也不會復(fù)現(xiàn)出來，反正收藏起來可能就是學(xué)會了。

現(xiàn)在遇到各種垃圾的硬編碼代碼，沒有任何注釋，也沒啥感覺了。別人吐槽爛代碼的時(shí)候，我都會安慰下，讓他們看看我遇到過線上環(huán)境更爛的代碼。

注釋變少，文章越寫越短，看垃圾代碼也不氣了，或許是我變強(qiáng)了。