很有共鸣。 关于工程能力这块说得太对了，而且举例也是跟我自己的情况基本一样。 我刚进公司的时候也是计算机基础和技术自认为比较出色的，但是真的在做项目ticket的时候就遇到了一样的问题。对于需求的理解不到位，一看之下不太会做也不求前辈们教，之间一拖总是把好多ticket完成的时间拖得很长很长。后面经过组长的细心调教，现在已经好多了。组长说，ask more, work as a team.

因为掌握门槛高，所以才值得投入时间去学习。试想如果你几小时就能学会的技能，其他人也同样可以，反复在这样的层次上投入，其实是一种浪费。看过徐老师的编码视频，才能体会到童子功的重要性和高回报。

不仅想自己掌握这项技能并且变成工作中的主要方式之一，还想带动身边人一起！！！

我觉得光是这一讲加餐就值回票价了。 2023年的第一件重要的事就是跟着课程掌握TDD开发。 1. 工程能力和技术能力同等重要。 2. 工程能力是团队协作、长期稳定、持续提高。 3. TDD为什么是最具工程效能的实践。 4. TDD、重构、架构的关系。 5. TDD的学习、实践方法。

这些重构手法太牛了，看得我眼花缭乱

高手之上的高高手

期待与徐昊老师再会，听徐昊老师分享和写代码是一种非常愉悦的享受。

在多个类出现重复的代码，是散单式修改的坏味道

23敲好的代码 https://github.com/vfbiby/tdd-di-container

我怎么觉得对于这种编排类型的组件的测试来说好像建立在抽象上的测试才是一个比较正确的做法呢？因为如果测试要测试的是意图而不是实现，那么我的理解就是你的编排型的组件必须得非常抽象，你才能做到测试意图呢？比如说，我要测试下单流程，可能下单的流程里还要支付，那现在我的下单依赖了支付组件，那也只能依赖抽象而不是具体的实现，这样我的单元测试可能就直接mock 抽象出来的interface PaymentProvider 而不用取关心具体的实现，这样以后即便我再怎么改我的下单的流程，只要业务上还需要支付我都可以不需要修改我的测试，这样不是挺好的么？当然了，你越接近具体实现，你的代码修改，你确实是要改的，但是你起码控制了你的修改面，不至于你实现细节的修改还要去修改上层的模块的测试。