Golang

关注公众号 jb51net

关闭
首页 > 脚本专栏 > Golang > Go本地测试解耦任务拆解

Go本地测试小技巧解耦任务拆解

作者:王中阳Go

这篇文章主要为大家介绍了Go本地测试解耦任务拆解及沟通详解,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪

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的好习惯,更多关于Go本地测试解耦任务拆解沟通的资料请关注脚本之家其它相关文章!

您可能感兴趣的文章:
阅读全文