來點小匠心--一個小迭代的代碼實現及調優

問題

我司對外部商戶提供的API中，有一個年久失修的開票記錄查詢接口，近期在一次集中測試時，發現這個接口的響應值與接口文檔裏描述的不一致。代碼裏定義的field名是type，而文檔裏參數名是invoiceTypeId。

修改方案

因爲無法確定原先的type有沒有商戶在用，所以，在模型類裏新增invoiceTypeId，以保證與文檔一致。

 

代碼實現

先介紹這個模型類QueryInvoiceResultResponse，是一個普通的POJO，一堆field，一堆getter&setter，往下翻還有個使用IDE生成的toString方法，洋洋灑灑300餘行代碼。

代碼怎麼改呢？
這還不太簡單！新增一個名爲invoiceTypeId的私有field，併爲其增加getter&setter，再在聲明這個對象的業務類裏，調setInvoiceTypeId，妥了。

是的，就是這麼簡單。

 

once you do, do it well. 我們來看更好的代碼實現方式

下面兩點，各位判官評判一下是否可以體現出來一點點匠心精神。

1）比較type與invoiceTypeId這2個字段名，不難看出type無法完整表達其含義，invoiceTypeId更優。既然如此，我們將type隱藏起來，不讓業務類裏再關注type，只需關注invoiceTypeId即可。另外，既然保留了type，那麼，就要在其javadoc裏註明保留的背景和原因，便於後續維護理解。

2）再說說這個300餘行的POJO類，顯然缺乏代碼簡潔度。在需求不斷迭代過程中，我們不應該總是新增代碼，而要適時調優代碼。就拿這個POJO來說，我們做一番小改造，首先用lombok的@Data註解來取代getter&setter，以及IDE快捷生成的toString方法。這些都是舉手之勞，卻能帶來極好的效果。這次CR時我就發現開發人員遺忘了重新生成toString方法，致使toString方法中沒有體現新增的invoiceTypeId，這對於一個300餘行代碼的POJO類來說是很容易漏掉的，因此，我們完全藉助lombok的@Data或@ToString就好了，沒必要自己每次都生成。

/**
 * 查詢開票結果返回實體
 *
 * @Author :  peanut
 * @Created : 2020/11/23 下午11:16
 */
@Data
public class QueryInvoiceResultResponse {
    /**
     * 服務商ID
     **/
    private Long levyId;
    /**
     * 商戶號
     **/
    private String merId;
    /**
     * 發票類目。 2023-5-15經驗證發現對外暴露API裏，發票類目參數名是{@link #invoiceTypeId}，但不確定這個type是否有商戶使用，暫時保留
     **/
    private Long type;
    /**
     * 發票類目id
     */
    private Long invoiceTypeId;
    /**
     * 申請開票金額（單位：分）
     **/
    private Long amt;

    ...
    ...

    public void setInvoiceTypeId(Long invoiceTypeId) {
        this.invoiceTypeId = invoiceTypeId;
        this.setType(invoiceTypeId);
    }

    /**
     * 不再對外暴露setType方法
     * @see #setInvoiceTypeId(Long) 
     * @param type
     */
    private void setType(Long type) {
        this.type = type;
    }
}