Go本地測試的思路

我習慣在開發過程中及時測試自己開發的功能模塊，這樣能及時發現問題，節省后期功能耦合之后，debug的時間。

為了統一管理要測試的功能（模塊），所以創建了測試類，在cmd中直接運行，不需要借助postman等接口請求工具。

fun Run(){
//測試方法
TestUnifyInputInsert()
}
func TestUnifyInputInsert() {
   var req *goods_unify.GoodsPackItem{} //這是結構體
   //這是json
   jsonInput := `{"base":{"goods_code":"381318","source":2,"shop_id":"1","shop_name":"京東自營測試","description":"測試描述","category_id":["1389"],"brand_name":"Bigen"},"attributes":[{"key":"產地1","value":"北京"}],"price":{"market_price":1000,"guide_price":900,"agreement_price":800,"activity_price":800}}`
   //把json轉成結構體
   err := gconv.Struct(jsonInput, &req)
   if err != nil {
      g.Dump("轉換錯誤:", err)
      return
   }
   service.GoodsUnify.CreateGoods(context.Background(), req)
}

解耦

今天在重構之前的代碼，舉個例子：

之前關于商品中心的添加、更新、修改價格、修改商品信息、下架等功能邏輯，都耦合在同一個方法中。

根據標記區分要進行什么操作。

從代碼復用角度考慮，這樣設計確實能少寫很對代碼。

但是維護起來確實很頭大。

舉個具體的場景示例：

當更新商品價格時：之前的設計是也需要傳遞類似封面圖、屬性、來源等30+字段，并且和價格無關的信息也會進行運算，解耦做的非常差。

在解耦之后：只需要傳遞商品價格，和商品對應的各個規格的價格信息。

同時把價格計算相關的方法抽取出來，供修改價格和修改商品信息復用。（修改商品信息也支持修改價格。）

no情緒 & todolist

情緒一上來，智商就下去。

今天比較累，但是工作效率比較高，反思一下就是上面的原因，因為自己活力四射的時候往往帶有情緒：傲嬌的情緒也好、覺得被坑的情緒也罷。

當帶有情緒時，是無法深入思考的，所以會出現智商變低的情況。

今天以一個比較累，比較困，但是記錄了todolist，拆解了問題，然后就這樣悶頭解決了各個問題。

現在反思一下今天的工作還是很爽的。

溝通的重要性

溝通真的非常重要，想起黃教主說的：“我不要你覺得，我要我覺得”。 老板們不都是黃教主...

今天和一個朋友談心，她聊到了最近工作中的困惑和煩惱。

我耐心聽她講完后，幫她總結就是溝通的問題：她總是以為工作中碰到的問題是什么樣的，其實事實并非如此。不愿意去溝通，甚至沒有主動溝通過，憑借自己的主觀臆斷去推進工作。

如果一如既往的“我覺得...我以為...”，不僅于事無補，情況只會越來越糟。

及時溝通

不要拖延、不要犯懶，問題只會隨著時間的拖延而越來越嚴重。

找對人

我認為當碰到問題時或者需要公司支持時，一定要和自己的直接領導做好溝通，因為直接領導是最了解咱們工作情況的，同時又能站在比自己高的角度去思考，能更好的理解老板的所思所想。

不要跨級溝通是有道理的，跨級可能會導致理解偏差。

公司之所以需要職級，需要一個蘿卜一個坑，是因為在組織架構中、公司文化中、長久的發展中形成的，我現在開始信這句話了：存在即合理。

當碰到問題時，找到對的人，進行及時溝通是非常非常重要的！

總結

調試小技巧的思路拋磚引玉，大家可以參考一下。