目录
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本地测试解耦任务拆解及沟通详解的详细内容,更多关于Go本地测试解耦任务拆解沟通的资料请关注三水点靠木其它相关文章!
Go本地测试解耦任务拆解及沟通详解Go本地测试的思路沟通的重要性总结
- Author -
王中阳Go- Original Sources -
声明:登载此文出于传递更多信息之目的,并不意味着赞同其观点或证实其描述。
Reply on: @reply_date@
@reply_contents@