【肥朝】編碼不規範，同事究竟幾行淚？

前言

案發現場

咱們在Dubbo中定義一個接口，這個接口採用上方說的欺騙性的命名方式，這個getFeiChaoInfo()中並無返回值。

好了，而後咱們將這個服務暴露，而後啓動。按照肥朝以前的觀念，命名不規範，無非是理解起來噁心了點，可是跑仍是能跑的。結果一啓動

以前看過我Dubbo源碼解析的同窗，對這個服務暴露再熟悉不過了，根據異常棧，咱們很快定位到了關鍵位置。

就算你連Dubbo都沒用過也不要緊，其實你從javassist和CannotCompileException這兩個關鍵詞就能猜到異常的緣由。javassist經常使用於操做字節碼，CannotCompileException根據我小學三年級的英語都知道是沒法編譯異常。那爲何出現沒辦法編譯經過呢？咱們把這段Dubbo拼接出來，準備要用javassist進行編譯的代碼格式化一下就一目瞭然了

格式化後就很明顯能夠看出，getFeiChaoInfo()這個方法沒有返回值是編譯不過去的。那麼這個時候有同窗就想說了，Dubbo這段拼接代碼進行編譯的邏輯有bug啊。鑑於公衆號目前有小部分粉絲沒用過Dubbo，咱們先不討論Dubbo爲何要這麼作，咱們檢討一下本身，你這種欺騙性的方法名自己就有問題，再者，就算Dubbo把這個代碼的容錯性作好了又如何，你這種不規範的編碼習慣，就算成功，也是偶然成功！，不信？肥朝帶你再看一個案發現場。

又一塊兒案發現場

在項目中，咱們常常會遇到DTO、BO、DO等轉換的問題，不少同窗用的是Apache或者Spring的BeanUtils來作copy，咱們來一組性能測試

場景	耗時(1000000次調用)	原理
get/set方法	22ms	直接調用
使用BeanCopiers	22ms	基於cglib，修改字節碼
使用BeanUtils	12983ms	反射
使用PropertyUtils	3922ms	反射

另外肥朝給你們總結了一條結論

凡是和反射相關的操做，基本都是低性能的。凡是和字節碼相關的操做，基本都是高性能的。

因而可知，在各類POJO間轉化，最高性能的確定是直接操做get/set，可是這樣寫，確定不夠優雅。從性能報告明顯看出較優方案是使用cglib的BeanCopiers。BeanCopiers怎麼使用這個本身搜索一下就知道了，那麼咱們再來看一塊兒案發現場。爲了使用建造者模式，咱們有同事這麼作

好了。而後跑一個簡單的demo

看到有異常一些同窗就慌了，就產生了這個東西雖然性能高，可是感受好像不穩定的樣子錯覺。其實並非這東西不穩定，關鍵仍是在於你會不會用。再說了，世界天天都在變，除了肥朝會穩定給你們輸出原創以外，還有什麼是穩定的呢？爲此，肥朝給你們總結了如下幾點使用上的常識

1.當源類和目標類的屬性名稱、類型都相同，拷貝結果棒棒噠。

2.當源對象和目標對象的屬性名稱相同、類型不一樣,那麼名稱相同而類型不一樣的屬性不會被拷貝。另外注意，原始類型（int，short，char）和 他們的包裝類型，在這裏都被當成了不一樣類型。所以不會被拷貝。

3.源類或目標類的setter比getter少，拷貝沒問題，此時setter多餘，可是不會報錯。

4.源類和目標類有相同的屬性（二者的getter都存在），可是目標類的setter不存在，此時會拋出NullPointerException

關鍵是咱們目標類FeiChaoBO的setter方法是存在的啊，那爲何還會出現這個異常？很明顯，正常的set方法都是void的。然而這個案例中，set方法設置了返回值，存在必定的欺騙性。並且就算要用建造者模式也不是這麼用的，再退一萬步說，建造者模式通常也是build命名而不是改set方法。

你再注意觀察一下這兩個案發現場，有沒有發現一些共同的特色？javassist和cglib，這兩個框架最擅長的就是操做字節碼，因此他們對set和get，都和如白紙版清純的肥朝同樣，很是的敏感！因此建議老司機也不要隨便亂動。

另外，據肥朝瞭解到，這個cglib的這個bug在3.1之後的版本是修復了的，可是3.1版本，目前使用的基數仍是很大

拓展思考

看過肥朝文章的粉絲都知道，肥朝反覆強調要通過深度思考，開發中咱們有無數的坑，不可能所有踩完的，關鍵是要通過一個坑，深度思考，提升編碼意識！所以，按照老套路，看看根據此次經驗，咱們試着再壓榨出一些有效信息。

好比阿里開發手冊提到了，getter和setter方法中，不要增長邏輯。由於你們意識裏面的getter和setter就是正常的獲取屬性，你若是加上了必定的邏輯，從必定程度上說，也存在欺騙性.

咱們再繼續壓榨，布爾類型的get方法有些工具會生成isXXX，這個其實也是有坑的，固然也不排除你項目正在處於肥朝口中的偶然成功狀態。

因而可知，取名是一個很大的學問，規範的命名是很是重要的，好比肥朝這麼見名知意的名字，明顯是通過深度思考得來的。有時候我真的很羨慕你們，天天都有這麼多豐富多彩的故事，不像我，一個簡簡單單的」肥「字居然就貫穿了一輩子！

寫在最後

本文僅爲冰山一角，上百篇原創乾貨還在路上，掃描下面二維碼關注肥朝，讓天生就該造火箭的你，再也不委屈擰螺絲！