老师通过教助力学，已经达到了知识学习的第三境界。我也打算借鉴这种方式，在团队内部分享学习心得提升知识熟练度。

非常感谢老师的分享，吸收了很多新的想法，并能改进现在的工作，感觉特别开心😄

很早就从王淮的《打造 Facebook 帝国》了解了 Facebook 文化，这次跟着葛老师从研发效能视觉又学习到很多细节，感谢老师。 师傅领进门，修行靠个人，是结束也是新的开始。

看完专栏，收获很多，尤其是对于打造流畅的开发环境，良好的开发体验感触深刻，也让我更加有自信跟公司去申请让团队配置更好的机器，网络环境，打造舒适的开发体现，我特别相信只有良好的土壤才能诞生高质量的软件，也只有好的环境才能吸引高质量的人才，加油吧，软件的路还有很长

断断续续，总算是把大佬的课程学完了。受益颇多，而我也旨在通过各种工具和方式来提高团队和个人的研发效能，这篇专栏还会再听几遍

数字3原则特别好，只能选3个，少就是多。 拥抱无聊摆脱手机依赖学习了，后面实践夏。 谢谢！

文章写得真好。我目前也在负责团队内部的效能提升（G家），从你的分享里收获了很多。同时也在打算近期回国，关于国内程序员的开发环境和工作环境也希望有机会能尽自己所能帮忙改善

研发效率的提升来源于这样的一个个小的优化点，看起来小，但是对效率提升确实很大。应该给与足够的重视。 这个列子让我想起在工作中遇到的同类型案列：当时在shein工作时，由于灰度环境只有一个，每次发版都的协调灰度环境的使用权和使用时间，如果前面的使用者超时，就会导致我们的灰度测试时间不够，甚至影响到我们的上线时间。而且每次灰度测试的发布时间都在半小时以上，非常影响到研发测试的效率。当时也和公司提过在搭一套灰度测试环境，但是公司给的回复是非常麻烦，也就不了了之，现在想想，是自己当时的认知不够，不能从更高的角度看待这个问题，才会导致可以改善的点，因为一点点挫折，就放弃了。反思：全体员工的认知不够，是导致这个问题长期存在的关键。

终于搞懂了持续交付和持续部署的区别，主要就是前者仅限于非生产环境，目的是随时随地提供可部署的软件；后者则是直接部署到生产环境中。看老师的观点，也就是提交量很大的情况才会考虑到持续部署。鉴于我们公司的提交量还处于excel checklist的可以摆平的状况，持续部署应该在很长的时间内不需要我去担心了……重点关注持续集成和持续交付上

这篇很实用！赶紧把自己的工作台配置优化一下！