伴随着春天的脚步，迎来了今年长春敏捷社区的第一次线下活动——尹哲老师的代码工作坊。一天的编程工作坊刚一听会觉得会不会很枯燥呢？没想到时间过的飞快。老师风趣的讲解，小伙伴们结对编程的热火朝天，不同想法的碰撞，总是能引发对身边工作的思考。也总是会引起想马上尝试改变一下的冲动。相信小伙伴们都会获得各自的收获。仅用这篇文章将我自己的一些“AHA”时刻做个总结。
-
保持住你空手道姿势，你就是黑带了。
对老师今天的这句话印象深刻。如果你在面对任何高手的过程中，始终能够保持空手道的姿势，那你就是黑带了。对于程序员的我们正确的姿势是什么呢？答案是TDD。而你是否能在时间紧、任务重的情况下仍然能够保持这个姿势？就像空手道选手，光靠嘴说说肯定不行。要想保持程序员的姿势，需要大量的刻意练习才能做到。反观我们每个人平时的编码过程，是在练习自己的这些“功夫”？还是只是在做代码的搬运工？
codeworkshop.jpeg 关注测试简单内容。但是往往我们都是先关注有趣的部分
这个太有共鸣了。在听到一个练习题目之后，第一个在我们头脑中出现的思考是什么？例如FizzBuzz这个题目，我们思考的是第一个出现的数字“1”如何实现？还是Fizz或者Buzz何时出现的逻辑，我要如何实现？TDD最难的一个地方是找到最小的那个功能点开始实现，逐步展开。而当你一开始就卡在一步上无法下手的时候。肯定是这个待测试的功能还不够小。结对编程的新方式：一个人思考说想法，另一个人扮演smart keyboard
这个过程会让写代码的人尽可能的理解说的人的想法，并尽可能的还原到电脑上，如果没理解，会提出来让说的人解释，直到两人沟通一致为止。和一个人写测试一个人写功能实现这种思考博弈的结对不同，这种方式少了一些激烈的味道，多了一些平和的合作。不同的结对方式，都能引发参与者的沟通和思考。测试和检查不同。TDD是检查
第一次听到检查和测试的不同。代码是否合理是通过开发人员自己的测试来检查的，而代码是否满足了业务逻辑，是通过测试来验收的。我们实际的工作中，开发人员用什么方法来检查自己的代码是否按照预期运行呢？又有多少是让测试人员来帮忙检查的，做了检查工作的测试人员，还有多少时间去做业务验证的测试呢？想一想都有些惭愧了。最大化同步依赖，降低异步依赖
乍一听到这句话的时候还有些疑惑。不应该想办法降低依赖吗？老师解释道，依赖是有它作用的，同步依赖及时会暴露问题，更早的发现阻碍，逼着我们想办法尽快移除。而实际中往往大家都是尽可能通过异步化来降低依赖。但是这种并不是去除依赖，只是延长了问题反馈的时间。反而增加了风险。加入TCR（test && commit || revert)限制
一个有意思的练习工具。通过一个脚本实现执行单元测试->测试通过->提交，或者测试失败->会滚。第一次玩TCR的时候发现一旦测试不通过，辛苦写的代码全都没了。这个刺激呀。不过带来的思考是：为什么会有心疼的感觉？因为写的东西很多，一下子就没了。那为什么要写那么多代码呢？一次性要测试的内容太多了。是不是要控制一下小步前进？如果每次都是很小的内容，那错了回滚是不是也就没什么心疼的了。正好重新开始。TCR这个“小夹板套”让我们开始思考：你是不是想多了！FAST，WORK，RIGHT你是如何排序的
首先make it work，之后重构让他保持right，有必要才去让他更fast。但是如何才是够fast，fast的定义是什么呢？是否有必要追求fast？可能我们平时更多的是连work都还没有做到。
引用尹哲老师的寄语，和有匠心精神的小伙伴们共勉：
愿各位年轻的朋友能呵护好自己的这份热情。多样的人生经历自然有用，但是别忘了也别丢了你最热爱也是最重要的手艺。
践行敏捷实践，让工作去繁从简。欢迎留言，交流落地经验。