大家好，我是解決一個bug，產生三個bug的程式設計師，所以大家都叫我三bug。
前一陣子我又解決了一個bug，看看是什麼情況吧！
問題現場
我正在愉快地寫bug，寫完之後測bug，結果發現了一個bug：
java.sql.SQLException: xxxx : Column 'status' not found in any table
我們的ORM框架使用的是MybatisPlus，這個問題是在我使用這個apid時產生的：
this.baseMapper.selectBatchIds(ids);
問題分析
這個bug也很清晰，有一個欄位 status 沒有找到。
因為用的是MP封裝的方法，沒有自己寫xml，所以是實體類的欄位和資料庫欄位對應不上。
但奇怪的在哪，因為我很確定，我的實體類中沒有status這個欄位。
外事不決問百度，內事不決問同事。
我問了一下同事，有沒有遇到過這個問題？
—— 遇到過了。
怎麼解決的？
—— 資料庫新增 status欄位。
問題到這就結束了嗎？當然沒有。我們的資料庫設計都是定好規範的，憑白往裡面新增一個欄位，這種解決方式是我不能接受的。
問題的突破口在哪？
要搞清楚sttus 到底是定義在哪的。我在Idea裡全域性搜尋了一下，沒有搜尋到。
但是仔細檢視了一下實體類，
extends EcEntity
嗯，他還有一個父類。
點進去看一下，這個類有五個欄位：createUser、createTime、updateUser、updateTime、delFlag。
還是沒有status，別急，這個類還有個父類。
extends BaseEntity
點進去一看：
public abstract class BaseEntity implements Serializable {
@ApiModelProperty("業務狀態")
private Integer status;
……
}
破案了，原來status是在這兒。為什麼搜不到，原來是封在了jar包裡。
問題解決
status 找到了，我們也動不了。
問問架構組同學這個欄位是幹什麼的。
—— 有些業務資料庫設計裡用上了這個欄位，所以抽取出來。
好吧，可是，我們用不上啊。
難道非得資料庫里加上這麼一個用不上的欄位？
當然不用，我之前看過MP的官方文件，裡面有個註解的屬性我稍微還有點印象。
什麼屬性呢？
查一下官方文件，就是它—— @TableField(exist = false)。
這個屬性是用來幹什麼的呢？是用來標識實體類中的非表欄位的。
在我的實體類中新增：
@TableField(exist = false)
private Integer status;
OK，問題解決。
解決問題的我紅光滿面，站起來，腆著肚子：
"各位老哥，過來一下。"
召集了小組的同事，把這個問題給他們一講，豪橫地說道：
“把資料庫里加的欄位都給我刪了，都按我的來。”
同事一臉欽佩，“這個問題你是怎麼想到的？”
我歪嘴一笑——“實力！”
三之感想
好了，這個簡單的小問題就處理完了。
問題很簡單，也有其它不太優雅的處理方式。
但是我們小組裡其它同事都沒有找到問題的原因和合適的處理方式，而我找到了呢？
- 我稍微閱讀過一點jdk的原始碼，所以不怵扒原始碼
- 我知道MP是我們新專案主要用的ORM框架，把官方文件過了一遍
這兩個條件缺一個，我可能就沒法以上面說的方式解決這個問題，而是以百度到的，資料裡新增欄位來解決。
這只是很小的一個問題，但是放大來看，有時候我們做重複性工作的時候想一想：
你抱怨每天都在crud，是不是你只有crud的能力呢？
當然不是在座的各位，是說我自己。
就像上面的問題，是架構組的同事封裝MybatisPlus留的一個坑。我也不敢吐槽，因為我沒那個實力。
假如他們做的這個需求給我：優化和封裝開源框架MybatisPlus。
我也幹不了，因為不瞭解MP的相關原理，沒有扒過原始碼，百度也查不到什麼資料。
平時，學習原理、閱讀原始碼常常發生在什麼時候？
——準備面試的時候。
我們雖然常常吐槽面試造火箭，入職擰螺絲,但是，這些造火箭的東西可不止在面試時候有用——
- 遇到問題救命：日常開發很簡單，遇到問題，沒有知識儲備很可能下不了手。
- 有機會能頂上：萬一有一些有技術含量的工作分派，想做，但是做不了，只能看著分給別人，不得難受死。
所以，保持學習，注意積累！
簡單的事情重複做，重複的事情認真做，認真的事情創造性地做。
點贊、關注不迷路！我們們下期見！