背景

阿裡java開發規範是阿裡巴巴總結多年來的最佳編程實踐，其中每一條規範都經過仔細打磨或踩坑而來，目的是為社區提供一份最佳編程規範，提升代碼質量，減少bug。
這基本也是java業界都認可的開發規範，我們團隊也是以此規範為基礎，在結合實際情況，補充完善。最近在團隊遇到的幾個問題，加深了我對這份開發規範中幾個點的理解，下麵就一一道來。

日誌規約

這條規範說明瞭，在異常發送記錄日誌時，要記錄案發現場信息和異常堆棧信息，不處理要往上throws，切勿吃掉異常。
堆棧信息比較好理解，就是把整個方法調用鏈列印出來，方便定位具體是哪個方法出錯。而案發現場信息我認為至少要能說明：“誰發生了什麼錯誤”。
例如，哪個uid下單報錯了，哪個訂單支付失敗了，原因是什麼。否則滿屏列印：“user error”，看到你都無從下手。

在我們這次出現的問題就是有一個feign，調用外部介面報錯了，降級列印了不規範日誌，導致排查問題花了很多時間。偽代碼如下：

	@Slf4j
	@Component
	class MyClientFallbackFactory implements FallbackFactory<MyClient> {		

		@Override
		public MyClient create(Throwable cause) {
			return new MyClient() {
				@Override
				public Result<DataInfoVo> findDataInfo(Long id) {
					log.error("findDataInfo error");
					return Result.error(SYS_ERROR);
				}
			};
		}
	}

發版後錯誤日誌開始告警，打開kibana看到了滿屏了：“findDataInfo error”，然後開始一頓盲查。
因為這個介面本次並沒有修改，所以猜測是目標服務出問題，上伺服器curl介面，發現調用是正常的。
接著猜測是不是熔斷器有問題，熔斷後沒有恢復，但重啟服務後，還是繼續報錯。開始各種排查，arthas跟蹤，最後實在沒辦法了，還是老老實實把異常列印出來，走發版流程。

log.error("{} findDataInfo error", id, cause);

有了異常堆棧信息就很清晰了，原來是返回參數反序列失敗了，介面提供方新增一個不相容的參數導致反序列失敗。(這點在下一個規範還會提到)
可見日誌列印不清晰給排查問題帶來多大的麻煩，記住：日誌一定要列印關鍵信息，異常要列印堆棧。

二方庫依賴

上面提到的返回參數反序列化失敗就是枚舉造成的，原因是這個介面返回新增一個枚舉值，這個枚舉值原本返回給前端使用的，沒想到還有其它服務也調用了它，最終在反序列化時就報錯了，找不到“xxx”枚舉值。
比如如下介面，你提交一個不認得的黑色BLACK，就會報反序列錯誤：

	enum Color {
		GREEN, RED
	}

	@Data
	class Test {
		private Color color;
	}

	@PostMapping(value = "/post/info")
	public void info(@NotNull Test test) {

	}

	curl --location 'localhost/post/info' \
	--header 'Content-Type: application/json' \
	--data '{
    	"testEnum": "BLACK"
	}'

關於這一點我們看下作者孤盡對它的闡述：

這就是我們出問題的場景，提供方新增了一個枚舉值，而使用方沒有升級，導致錯誤。可能有的同學說那通知使用方升級不就可以了？是的，但這出現了依賴問題，如果使用方有成百上千個，你會非常頭痛。

那又為什麼說不要使用枚舉作為返回值，而可以作為輸入參數呢？
我的理解是：作為枚舉的提供者，不得隨意新增/修改內容，或者說修改前要同步到所有枚舉使用者，讓大家知道，否則使用者就可能因為不認識這個枚舉而報錯，這是不可接受的。
但反過來，枚舉提供者是可以將它作為輸入參數的，如果調用者傳了一個不存在的值就會報錯，這是合理的，因為提供者並沒有說支持這個值，調用者正常就不應該傳遞這個值，所以這種報錯是合理的。

ORM映射

以下是規範里的說明：
1）增加查詢分析器解析成本。
2）增減欄位容易與 resultMap 配置不一致。
3）無用欄位增加網路消耗，尤其是 text 類型的欄位。

這都很好理解，就不過多說明。
在我們開發中，有的同學為了方便，還是使用了select *，一直以來也風平浪靜，運行得好好的，直到有一天對該表加了個欄位，代碼沒更新，報錯了~，你沒看錯，代碼沒動，加個欄位程式就報錯了。
報錯信息如下：

數組越界！問題可以在本地穩定復現，先把程式跑起來，執行 select * 的sql，再add column給表新增一個欄位，再次執行相同的sql，報錯。

具體原因是我們程式使用了sharding-jdbc做分表(5.1.2版本)，它會在服務啟動時，載入欄位信息緩存，在查詢後做欄位匹配，出錯就在匹配時。
具體代碼位置在：com.mysql.cj.protocol.a.MergingColumnDefinitionFactory#createFromFields

這個緩存是跟資料庫鏈接相關的，只有鏈接失效時，才會重新載入。主要有兩個參數和它相關：
spring.shardingsphere.datasource.master.idle-timeout 預設10min
spring.shardingsphere.datasource.master.max-lifetime 預設30min

預設緩存時間都比較長，你只能趕緊重啟服務解決，而如果服務數量非常多，又是一個生產事故。
我在sharding sphere github搜了一圈，沒有好的處理方案，相關鏈接如：
https://github.com/apache/shardingsphere/issues/21728
https://github.com/apache/shardingsphere/issues/22824

大體意思是如果真想這麼做，資料庫ddl需要通過sharding proxy，它會負責刷新客戶端的緩存，但我們使用的是sharding jdbc模式，那隻能老老實實遵循規範，不要select * 了。如果select具體欄位，那新增的欄位也不會被select出來，和緩存的就能對應上。
那麼以後面試除了上面規範說到的，把這一點親身經歷也擺出來，應該可以加分吧。

總結

每條開發規範都有其背後的含義，都是經驗總結和踩坑教訓，對於團隊的開發規範我們都要仔細閱讀，嚴格遵守。可以看到上面每個小問題都可能導致不小的生產事故，保持敬畏之心，大概就是這個意思了吧。

更多分享，歡迎關註我的github：https://github.com/jmilktea/jtea