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本地测试解耦任务拆解沟通的资料请关注编程网其它相关文章！
