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，拆解了问题，然后就这样闷头解决了各个问题。

现在反思一下今天的工作还是很爽的。

沟通的重要性

沟通真的非常重要，想起黄教主说的：“我不要你觉得，我要我觉得”。 老板们不都是黄教主...

今天和一个朋友谈心，她聊到了最近工作中的困惑和烦恼。

我耐心听她讲完后，帮她总结就是沟通的问题：她总是以为工作中碰到的问题是什么样的，其实事实并非如此。不愿意去沟通，甚至没有主动沟通过，凭借自己的主观臆断去推进工作。

如果一如既往的“我觉得...我以为...”，不仅于事无补，情况只会越来越糟。

及时沟通

不要拖延、不要犯懒，问题只会随着时间的拖延而越来越严重。

找对人

我认为当碰到问题时或者需要公司支持时，一定要和自己的直接领导做好沟通，因为直接领导是最了解咱们工作情况的，同时又能站在比自己高的角度去思考，能更好的理解老板的所思所想。

不要跨级沟通是有道理的，跨级可能会导致理解偏差。

公司之所以需要职级，需要一个萝卜一个坑，是因为在组织架构中、公司文化中、长久的发展中形成的，我现在开始信这句话了：存在即合理。

当碰到问题时，找到对的人，进行及时沟通是非常非常重要的！

总结

调试小技巧的思路抛砖引玉，大家可以参考一下。

平常的工作中一定要学会沟通、保持平稳的情绪、学会做任务拆解、养成每天做todolist的好习惯。