explain 一下

php -> go -> java。转 go 是团队技术栈变更；转 java 是跟另一个团队的领导聊了聊，正好他们也缺人，就过去了。

倒立更好，被 PM 坑的眼泪就不会流出来

restful 这东西没什么技术含量，谁都可以抒发一下个人见解，导致争论不休。到最后就变成个人品味的争执了，谁都说服不了谁。有时间有闲心的话可以去吵一吵，我先亮一下我的屁股，我是 paypal 规范的忠实支持者：

https://github.com/paypal/api-standards/blob/master/api-style-guide.md#http-status-codes

雨中冒险（ risk of rain ），玩起来就停不下来，我最喜欢卡 bug 刷一堆装备，最后站在那怪就全死了…

把 git log 发一下才好判断你同事的动机

是集体活动吗，如果是个人出行，看看能不能挪一下时间？

再补充一些，《 Practical Unit Testing with JUnit and Mockito 》这本书讲得比较细，可以看一看。

「我如果到时候改成调 dao 类的 getB 方法，测试代码也必须改」

应该改。单元测试主要是验证 SUT （ system under test ）本身的实现逻辑的正确性，你把实现逻辑都改了，单元测试当然也需要修改。比如你的例子，getA 改成 getB 方法，参数、返回有没有变更？有变更那 service 的代码就需要修改，service 修改了就需要单元测试确保修改的正确性；如果只是换个名字，现在 IDE 的重构功能可以把相关名称都替换了，也不需要手动修改。


「但是 mockito 这种测试代码和实际代码强耦合的情况，我必须把被测代码的所有其他类调用都找出来并且 mock 」

mock 是个测试替身，你不告诉它在被调用时应该怎么返回，它也不清楚你究竟想要什么。如果你不需要 mockito 的灵活性，完全可以为这个类写一个替身实现，然后在测试中使用这个替身类，就不需要在每个依赖这个类的地方都写一遍 mockito 代码了。


「写测试的时候，我假设我原来的代码没问题，才找调用出来 mock，而测出来肯定也没有问题呀」

mockito 主要还是在 TDD 中用得多些，你在写代码的时候，依赖类还没实现，这时候就需要用测试替身来完成单元测试。依靠 mockito 的灵活性，方便调整依赖类的入参返回，等上层实现稳定后，也就相当于依赖类的实现契约也建立好了，就可以根据这个契约再去实现依赖类...以此类推。如果是先写代码，再写测试，确实会有你这种感觉。

@JYChiu #3 我明白了，去设置里的 Keymap 看看，搜索一下 Declaration，配置一下快捷键，一般是配置 ⌘ + 鼠标左键（ Button1 Click ）

https://ws1.sinaimg.cn/large/6856d0b6gy1fzx37a4ju7j21940rg47s.jpg