我們經(jīng)常感嘆“面試造火箭，進(jìn)廠擰螺絲”，日常開發(fā)中大部分工作都是寫簡(jiǎn)單的業(yè)務(wù)代碼。實(shí)際上，寫好業(yè)務(wù)代碼也是有技術(shù)難度的，并不是所有人都能寫出可讀性較高的業(yè)務(wù)代碼。

可讀性高的代碼能夠降低后續(xù)的維護(hù)成本，提升后續(xù)開發(fā)的效率。

接下來(lái)和大家分享下我的經(jīng)驗(yàn)，這些方法能夠在一定程度上提升代碼的可讀性。

命名

Martin Fowler曾經(jīng)在一篇文章中曾經(jīng)引用過(guò)Phil Karlton的話：There are only two hard things in Computer Science: cache invalidation and naming things. “
在 CS 領(lǐng)域中，有兩件事是非常難的，一個(gè)是緩存失效，一個(gè)是命名。”

一致性

大項(xiàng)目中都是分工合作，不同領(lǐng)域由不同團(tuán)隊(duì)負(fù)責(zé)，同一領(lǐng)域也可能由多個(gè)人一起開發(fā)，因此即使對(duì)同一個(gè)事物命名，不同人也有不同的理解，因此對(duì)于關(guān)鍵業(yè)務(wù)名稱的命名需要統(tǒng)一，使整個(gè)鏈路保持一致性。

這個(gè)責(zé)任最好由項(xiàng)目PM擔(dān)起，在寫技術(shù)方案的時(shí)候，統(tǒng)一關(guān)鍵業(yè)務(wù)事物的命名。

有意義且簡(jiǎn)短

首先需要保證命名有意義，只要命名合理，不要擔(dān)心方法名稱太長(zhǎng)，但方法名稱過(guò)長(zhǎng)常常又意味著該方法干的事太多了，則需要思考是否可以拆分方法，這也反映了"職責(zé)單一"設(shè)計(jì)原則。

保證命名有意義的前提之下，盡量保證命名的簡(jiǎn)短，刪除一些不影響表達(dá)的單詞，或者采用縮寫。舉幾個(gè)例子：

ActivityRuleRepository.findActivityRuleById() 可以簡(jiǎn)寫成ActivityRuleRepository.findById()，因?yàn)樯舷挛囊呀?jīng)說(shuō)明白了這個(gè)一個(gè)查詢活動(dòng)規(guī)則的Repository接口。
void updateRuleForRevision(String ruleString) 簡(jiǎn)寫成void updateRule4Revision(String ruleStr)
ActivityRule convert2ActivityRule(String ruleStr) 借鑒toString的簡(jiǎn)寫方式，簡(jiǎn)寫成ActivityRule toActivityRule(String ruleStr)

遵循命名規(guī)范

Java的命名規(guī)范參考《阿里巴巴開發(fā)規(guī)約》中的命名規(guī)約，下面摘抄幾條命名規(guī)范復(fù)習(xí)下：

所有編程相關(guān)的命名均不能以下劃線或美元符號(hào)開始，也不能以下劃線或美元符號(hào)結(jié)束。
所有編程相關(guān)的命名嚴(yán)禁使用拼音與英文混合的方式，更不允許直接使用中文的方式。
代碼和注釋中都要避免使用（任何人類語(yǔ)言的）涉及性別、種族、地域、特定人群等的歧視性詞語(yǔ)。
類名使用UpperCamelCase風(fēng)格，以下情形例外：DO / BO / DTO / VO / AO / UID等。
方法名、參數(shù)名、成員變量、局部變量都統(tǒng)一使用lowerCamelCase風(fēng)格。
常量命名應(yīng)該全部大寫，單詞間用下劃線隔開，力求語(yǔ)義表達(dá)完整清楚，不要嫌名字長(zhǎng)。
POJO類中的任何布爾類型的變量，都不要加is前綴，否則部分框架解析會(huì)引起序列化錯(cuò)誤。

區(qū)分作用范圍

作用范圍可以分為應(yīng)用、包、類、方法、代碼塊，在大的作用域范圍應(yīng)該盡量使用完整有意義的命名，但是在方法和代碼塊內(nèi)可以考慮使用短名稱，因?yàn)樽兞孔饔梅秶芯窒扌?，上下文一眼可知，變量的含義也就無(wú)需過(guò)多說(shuō)明。

如果小作用范圍依然使用長(zhǎng)命名會(huì)導(dǎo)致很容易超過(guò)列寬，即使折行也難以閱讀。如下所示，方法內(nèi)采用簡(jiǎn)短的命名方式。

void updateRule4Revision(String ruleStr) {    ActivityRule rule = toActivityRule(ruleStr);    int oldVersion = rule.getVersion();    rule.setVersion(++oldVersion);    activityRuleRepository.save(rule);} 

體現(xiàn)副作用

如果方法實(shí)現(xiàn)會(huì)產(chǎn)生副作用，該副作用需要體現(xiàn)在方法名稱，舉個(gè)可能不太恰當(dāng)?shù)睦樱旅娴姆椒ㄔ隍?yàn)證規(guī)則的同時(shí)去激活規(guī)則的狀態(tài)，如果規(guī)則已經(jīng)是激活狀態(tài)則狀態(tài)沒(méi)有變化，如果規(guī)則不是激活狀態(tài)則狀態(tài)被改變。

一般我們應(yīng)該保持方法的單一職責(zé)，但是有些特殊情況導(dǎo)致了妥協(xié)，那么一定要在方法命名上面體現(xiàn)。

boolean verifyRuleAndActivateStatus(Rule rule) {    // verify rule    ......    rule.activateStatus()    ......} 

閱讀優(yōu)秀的開源代碼

英語(yǔ)不是我們的母語(yǔ)，這導(dǎo)致我們命名更加困難，我們可以通過(guò)閱讀優(yōu)秀的開源代碼提升詞匯量，熟悉英語(yǔ)母語(yǔ)開發(fā)者的命名思維習(xí)慣。

也并不是所有的開源項(xiàng)目的代碼可讀性都很高，有些為了追求極致的性能損失了部分可讀性，如果不知道學(xué)習(xí)哪個(gè)開源項(xiàng)目，那就學(xué)習(xí)spring-boot項(xiàng)目，下面截圖是spring-boot項(xiàng)目中的代碼，命名方式值得學(xué)習(xí)。

使用Optional

優(yōu)雅判空

NullPointerException是Java程序員無(wú)法言語(yǔ)的痛，為了避免空指針異常，我們通常需要做非常多的防御性編程，if判空是最簡(jiǎn)單的方式，但是充斥大量著if判空的代碼會(huì)淹沒(méi)核心代碼邏輯，導(dǎo)致可讀性差。

下面舉一個(gè)例子:

Optional優(yōu)化前：

public Long parseUmpActivityId(PlayApplyContext applyContext) {    if (applyContext == null || applyContext.getPlayDetailDO() == null         || StringUtil.isBlank(applyContext.getPlayDetailDO().getDetail())) {        return null;    }    Map<String, String> playDetailMap = toPlayDetailMap(applyContext.getPlayDetailDO().getDetail());    if (playDetailMap == null) {        return null;    }    String umpActivityIdStr = playDetailMap.get(Constant.UMP_ACTIVITY_ID);    if (StringUtils.isBlank(umpActivityIdStr)) {        return null;    }    return Long.parseLong(umpActivityIdStr); 

Optional優(yōu)化后：

public Long parseUmpActivityId(PlayApplyContext applyContext) {    return Optional.ofNullable(applyContext)        .map(PlayApplyContext::getPlayDetailDO)        .map(PlayDetailDO::getDetail)        .map(this::toPlayDetailMap)        .map(m -> m.get(Constant.UMP_ACTIVITY_ID))        .filter(StringUtils::isNotBlank)        .map(Long::parseLong)        .orElse(null);} 

分支判斷

Optional的orElse具有分支判斷的能力，可以在一些情況下代替if，提升代碼的可讀性，如下場(chǎng)景所示，經(jīng)過(guò)三目運(yùn)算符的優(yōu)化依然可讀性不強(qiáng)，Optional優(yōu)化后才具有較高可讀性。

優(yōu)化前

......            Result<Long> result = apply(juItem);    if (result == null || !result.isSuccess()) {        if (result != null && result.getMsg() != null) {            return Result.buildErrorResult(result.getMsg());        }        return Result.buildErrorResult("創(chuàng)建失敗");    }    ...... 

三目運(yùn)算符優(yōu)化后：

......            Result<Long> result = apply(juItem);    if (result == null || !result.isSuccess()) {        return Result.buildErrorResult(            result != null && result.getMsg() != null ? result.getMsg() : "創(chuàng)建失敗");    }    ...... 

Optional優(yōu)化后：

......            Result<Long> result = apply(juItem);    if (result == null || !result.isSuccess()) {        return Result.buildErrorResult(            Optional.ofNullable(result).map(Result::getMsg).orElse("創(chuàng)建失敗"));    }    ...... 

陷阱

在使用Optional的orElse時(shí)候可能會(huì)誤入陷阱，舉一個(gè)具體的例子，如下所示的代碼存在問(wèn)題嗎？

這段代碼的作用是，當(dāng)傳入?yún)?shù)中activity不為空則取傳入的activity，否則通過(guò)接口根據(jù)活動(dòng)ID查詢，避免了無(wú)謂的查詢。

Result applyActivity(Params params) {    Activity activity = Optional.ofNullable(params)        .map(Params::getActivity)        .orElse(activityManager.findById(params.getActivityId()));        ......} 

以上代碼存在兩個(gè)問(wèn)題，第一，params.getActivityId()可能出現(xiàn)空指針異常，第二，activityManager.findById一定會(huì)被調(diào)用，無(wú)法達(dá)到預(yù)期的效果。

而這兩個(gè)問(wèn)題的根本原因都是因?yàn)閛rElse方法傳入的是語(yǔ)句執(zhí)行之后的結(jié)果。

所以在orElse方法中最好不要傳入執(zhí)行語(yǔ)句，而應(yīng)該是默認(rèn)值。

上面應(yīng)該這種情況正確應(yīng)該使用orElseGet，orElseGet傳入的是函數(shù)。

正確換行

Optional方式編程很大程度提升了代碼的可讀性，寫代碼如行云流水一般，為了更好的閱讀，需要采用正確的換行方式，最好是一行一條Optional語(yǔ)句，如下圖所示，這樣換行的好處就是，一行做一件事情，閱讀流暢。

而且最重要的是IDEA在每條語(yǔ)句后面提示了返回結(jié)果的類型，這個(gè)提示不僅僅對(duì)閱讀有幫助，對(duì)編寫代碼也有很大幫助。這個(gè)原則同樣適用于Lambda表達(dá)式的編寫。

當(dāng)然，對(duì)于非常簡(jiǎn)單鏈?zhǔn)秸Z(yǔ)句可以打破以上原則，比如context.setActivityId(Optional.ofNullable(activityId).orElse(0L));

使用Lambda

關(guān)于Lambda表達(dá)式編程的好處和用法想必大部分人都清楚，正確使用Lambda表達(dá)式可以很大程度提升代碼的可讀性，但是不正確使用Lambda表達(dá)式會(huì)給可讀性帶來(lái)更大的災(zāi)難。

拒絕匿名函數(shù)

如下函數(shù)的功能是根據(jù)活動(dòng)信息獲取活動(dòng)中的所有報(bào)名記錄，采用了普通的for循環(huán)編寫，嵌套比較深，代碼含義不是很明確，有優(yōu)化的空間，接下來(lái)采用Lambda表達(dá)式進(jìn)行優(yōu)化。

private List<Record> obtainRecords(List<Campaign> campaignList) {    List<Record> recordList = Lists.newArrayList();    for (Campaign campaign : campaignList) {        if (campaign.getStartTime() != null && campaign.getStartTime().getTime() < System.currentTimeMillis()            && campaign.getStatus() > 0) {            Params params = new Params();            params.setCampaignId(campaign.getId());            params.setStartTime(campaign.getStartTime());            params.setStatus(campaign.getStatus());            List<Record> originRecordList = campaignRecordFacade.query(params);            for (Record record : originRecordList) {                if ((record.getStatus() <= INIT && PLAY_TYPE.equals(record.getType()))                    || record.getStatus() == AUDIT_PASS) {                    recordList.add(record);                }            }        }    }    return recordList;} 

采用Lambda表達(dá)式重新編寫后如下所示，一定程度上提升了代碼的可讀性，是否還具有提升空間呢。

其中匿名函數(shù)占據(jù)了大部分代碼邏輯，導(dǎo)致主流程不清晰，在使用Lambda表達(dá)式的時(shí)候應(yīng)該盡量不要使用匿名函數(shù)。

private List<Record> obtainRecords(List<Campaign> campaignList) {   return campaignList.stream()        .filter(campaign -> campaign.getStartTime() != null            && campaign.getStartTime().getTime() < System.currentTimeMillis() && campaign.getStatus() > 0)        .map(campaign -> {            Params params = new Params();            params.setCampaignId(campaign.getId());            params.setStartTime(campaign.getStartTime());            params.setStatus(campaign.getStatus());            return campaignRecordFacade.query(params);        })        .flatMap(Collection::stream)        .filter(record -> (record.getStatus() <= INIT && PLAY_TYPE.equals(record.getType()))            || record.getStatus() == AUDIT_PASS)        .collect(Collectors.toList());} 

去除匿名函數(shù)優(yōu)化后如下所示，主流程非常清晰，沒(méi)有閱讀障礙，函數(shù)名解釋了所做的具體事情，通過(guò)閱讀函數(shù)名而不是具體的代碼去了解這塊做了什么事情，具體閱讀某個(gè)函數(shù)時(shí)，只需要保證代碼邏輯符合函數(shù)名表達(dá)的含義。

private List<Record> obtainRecords(List<Campaign> campaignList) {    return campaignList.stream()        .filter(this::isValidAndAlreadyStarted)        .map(this::queryRecords)        .flatMap(Collection::stream)        .filter(this::isInitializedPlayOrAuditPass)        .collect(Collectors.toList());}private boolean isValidAndAlreadyStarted(Campaign campaign) {    return campaign.getStartTime() != null            && campaign.getStartTime().getTime() < System.currentTimeMillis() && campaign.getStatus() > 0;}private List<Record> queryRecords(Campaign campaign) {    Params params = new Params();    params.setCampaignId(campaign.getId());    params.setStartTime(campaign.getStartTime());    params.setStatus(campaign.getStatus());    return campaignRecordFacade.query(params);}private boolean isInitializedPlayOrAuditPass(Record record) {    return (record.getStatus() <= INIT && PLAY_TYPE.equals(record.getType())) || record.getStatus() == AUDIT_PASS;} 

結(jié)合Optional使用

Lambda表達(dá)式結(jié)合Optional使用可以更加簡(jiǎn)潔，如下所示查詢報(bào)名記錄后獲取報(bào)名記錄的ID，不使用Optional的時(shí)候需要判空等其他操作，Optional讓語(yǔ)句更加連貫。

這里需要注意一點(diǎn)，Collections.emptyList()返回的是一個(gè)不可變的內(nèi)部類，不允許添加元素，如果返回的結(jié)果需要添加元素，需要使用Lists.newArrayList()。

Optional.ofNullable(playRecordReadService.query(query))    .orElse(Collections.emptyList())    .stream    .fileter(this::isValid)    .map(Record::getId)    .collect(Collectors.toList()); 

用好異常

Checked Exception是Lambda表達(dá)式的天敵，因?yàn)樵贚ambda表達(dá)式中必須捕獲Checked Exception，這樣會(huì)導(dǎo)致Lambda表達(dá)式特別累贅。

針對(duì)這種情況，在系統(tǒng)內(nèi)部最好使用Runtime Exception，如果是外部接口申明了Checked Exception，那我們應(yīng)該在基礎(chǔ)設(shè)施層將外部接口封裝一個(gè)facade，facade只拋出Runtime Exception。

有一種系統(tǒng)設(shè)計(jì)，提倡系統(tǒng)內(nèi)部接口也使用Result作為返回結(jié)果，這種設(shè)計(jì)導(dǎo)致了很難流暢地使用Lambda表達(dá)式，因?yàn)槟愕拇a里面會(huì)充斥著大量if (!result.isSuccess())的判斷，如下代碼所示，queryRecordsByCampaign是一個(gè)RPC接口，可以看到代碼邏輯非常啰嗦，核心邏輯不明確。

Result<List<Record>> queryRecordsByCampaign(Campaign campaign) {    Result<Void> checkResult = checkCampaign(campaign);    if (!checkResult.isSuccess()) {        return Result.buildErrorResult(checkResult.getErrorMsg());    }    Result<Context> contextResult = buildContext(campaign);    if (!contextResult.isSuccess()) {        return Result.buildErrorResult(contextResult.getErrorMsg());    }    Result<List<Record>> queryResult = queryRecords(contextResult.getValue());    if (!queryResult.isSuccess()) {        return Result.buildErrorResult(queryResult.getErrorMsg());    }    if (CollectionUtils.isEmpty(queryResult.getValue())) {        return Result.buildSuccessResult(Lists.newArraysList());    }    List<Record> records = queryResult.getValue().stream()        .filter(this::isValid)        .map(this::compensateRecord)        .collect(Collectors.toList());    return Result.buildSuccessResult(records);}private Result<Void> checkCampaign(Campaign campaign) {    if (campaign == null) {        return Result.buildErrorResult("活動(dòng)不能為空");    }    if (campaign.getId <= 0) {        return Result.buildErrorResult("活動(dòng)ID非法");    }    return Result.buildSuccessResult();} 

另外一種系統(tǒng)設(shè)計(jì)，提倡系統(tǒng)內(nèi)部使用Runtime Exception控制異常流程，RPC接口不拋任何異常，使用Result表示返回結(jié)果。

上面的代碼經(jīng)過(guò)這種思想修改后的代碼如下所示，代碼簡(jiǎn)潔明了，Optional與Lambda完美配合。

其中關(guān)于參數(shù)校驗(yàn)和斷言可以參考apache工具包中的Validate設(shè)計(jì)適合自己應(yīng)用的工具類，通過(guò)Validate做校驗(yàn)非常簡(jiǎn)潔，并且可以自定義ExceptionCode來(lái)區(qū)分錯(cuò)誤類型。

但是，一定不要使用異常來(lái)控制正常流程。

Result<List<Record>> queryRecordsByCampaign(Campaign campaign) {    try {        checkCampaign(campaign);        List<Record> records = Optional.ofNullable(campaign)            .map(this::buildContext)            .map(this::queryRecords)            .orElse(Collections.emptyList())            .stream()            .filter(this::isValid)            .map(this::compensateRecord)            .collect(Collectors.toList());        return Result.buildSuccessResult(records);    } catch (Throwable t) {        log.error("an exception occurs ", t)        return Result.buildErrorResult(t.getMessage());    }}private void checkCampaign(Campaign campaign) {    Validate.notNull(campaign, "活動(dòng)不能為空");    Validate.gtzero(campaign.getId(), "活動(dòng)ID非法")} 

陷阱

《阿里巴巴開發(fā)規(guī)約》中提了兩點(diǎn)關(guān)于使用toMap()方法的陷阱，如下所示：

在使用java.util.stream.Collectors類的toMap()方法轉(zhuǎn)為Map集合時(shí)，一定要使用含有參數(shù)類型為BinaryOperator，參數(shù)名為mergeFunction的方法，否則當(dāng)出現(xiàn)相同key值時(shí)會(huì)拋出IllegalStateException異常。
在使用java.util.stream.Collectors類的toMap()方法轉(zhuǎn)為Map集合時(shí)，一定要注意當(dāng)value為null時(shí)會(huì)拋NPE異常。
另外，我們需要注意toList()可能導(dǎo)致FullGC，因?yàn)榧辖?jīng)過(guò)map后變成的類型可能占用很大內(nèi)存，流量高的時(shí)候會(huì)導(dǎo)致FullGC，這個(gè)時(shí)候需要采用forEach方式編程。

電商場(chǎng)景中最常見(jiàn)的大內(nèi)存對(duì)象就是ItemDO，一定不要批量獲取ItemDO保存在內(nèi)存中。

符合閱讀習(xí)慣

判斷長(zhǎng)度時(shí)，if (length >= 10)優(yōu)于if (10 <= length)。
判斷活動(dòng)是否已經(jīng)開始，if (startTime <= now && now <= endTime) 優(yōu)于 if (now <= endTime && startTime <= now)。
減少if嵌套，條件判斷的時(shí)候優(yōu)先判斷異常情況提前返回，if (!result.isSuccess()) { return false }，成功則繼續(xù)往下走。
如果if中的條件表達(dá)式比較復(fù)雜，將復(fù)雜的條件表達(dá)式封裝成一個(gè)函數(shù)，通過(guò)函數(shù)名來(lái)解釋表達(dá)式的含義。

寫在文末

以上只是從語(yǔ)言特性方面列出了一些簡(jiǎn)單的快速的提升代碼可讀性方法，其實(shí)還可以從很多方面入手，比如設(shè)計(jì)模式、架構(gòu)設(shè)計(jì)、事物抽象等。

關(guān)于架構(gòu)設(shè)計(jì)提升代碼可讀性方法，我比較認(rèn)同“領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)”思想，充血模型能夠解決復(fù)雜業(yè)務(wù)邏輯使代碼可讀性變差的問(wèn)題。

提升寫代碼的水平，是我們孜孜不倦的追求，從簡(jiǎn)單的業(yè)務(wù)代碼出發(fā)，寫出詩(shī)一樣的代碼。