EthanLin-TWer
commented
6 years ago 写的太好了。
最近看《娱乐至死》，看奕含的绝笔，慢慢有一个价值观产生：形式本身与内容同等重要。它的一个推论是，要做正确的事情。此处应该 @macdao
大家可能以为，思想（真理、道理）是一个实在存在的东西，只是用什么方式来表达它的问题，但它是存在的。那些想法存在于你的脑里，不管你是用写博客、和人交谈、录制视频、发社交媒体，它都是不变的一个思想，传播途径只是一个媒介，思想与媒介无关。《娱乐至死》告诉大家，错了。用什么方式表达不仅重要，而且影响你要表达的内容本身。
书里花大篇幅对比电视时代与印刷术时代，不同媒介本身对传播内容带来的不同。印刷术时代我们以书本为主要的交流途径，书本的表达方式是注重逻辑、事实、精心准备。而电视时代，我们首先看讲者的颜值高不高，播音者的声音是否吸引人，电视节目不容许思考，一个节目如果嘉宾现场花上5分钟准备论据以反驳对手，一定没人看这样的节目。我们的时间如此重要，以至于每时每刻都在刷信息，刷朋友圈，刷微博，一个手指滑上去就是好几个人一天的生活，我们忙到没时间花5分钟，停下来，等一个人将他的想法组织成思路。图像时代不需要阐述，不需要逻辑，只需要图。色彩鲜艳的图、让人若有所思的图、恍然大悟的图。人们没有时间进行深入阅读，就产生种种方便法门，比如抓人眼球的标题、目录清晰一眼5秒就能看清的文章、重点都帮你加粗标出的中心思想。种种这些，都是一个信息媒介所选择、所隐喻。你怎么还能说内容本身是独立于媒介存在的呢？
用奕含的话来讲，一个体系精巧，写出许多好的作品，思想真的不能说是不 美 的，本来应该是思无邪的艺术家，本人却虐打妻子，强暴女性。你要说艺术跟人品分开谈论，还是这样的艺术本身就是赝品，是一种巧言令色？
上面，使用 markdown 加粗、使用空格隔开突出的「美」字，也是一种表达方式，也是一种隐喻。而我慢慢觉得，这种表达方式也是我所舒服的。
所以回到 TDD 这个问题上，美静那天说，反正我们在分支上开发的代码最后都要合成一个提交，你自己在分支上进行小步提交是否觉得累？为什么不节省一下，大步一点，再大步一点？反正最后都只会变成一个提交，只要那个提交信息是详细的就行了。我回答，首先我觉得「分支开发」「合并提交」就不是正确的事情，只是因为项目现状使然；其次「节省」本身不是毫无成本，这种表达方式本身的隐喻是，小步提交是多余的，部分敏捷实践是多余可裁剪的，它鼓励你大步一点更大步一点地提交。这个隐喻本身是危险的，是错误的，是开发者自己技能不够熟练、实践不够持续集成所致，而不是实践本身的问题。所以，如果你真的感觉敏捷实践（以及其他任何东西）是有益（亲身确认是真的有益）的、正确的，就应该坚持。所以说要做正确的事情，对似乎无害的俭省实践说不。
JimmyLv
这些东西本来没有意义的。不过既然都记录了，就不带情绪地记录在这好了。上个项目带给我的成长是，用平和的心态面对阻力，同时加强个人能力修炼。不要在意微不足道的声音，进程的方向是对的。学习 TDD，一定就要看创始人的书、演讲，接下来的学习方向大概是：
我看到的现象是：
if-else- 质量不好 - bug 增多 - 修 bug 变紧急 - 质量不好无法收敛 bug - 只能往上继续堆代码 - 越来越紧急if-else- 质量不好 - bug 增多 - 修 bug 变紧急 - 质量不好无法收敛 bug - 只能往上继续堆代码 - 越来越紧急说白了都是人的问题和能力问题。
再来看看邮件组里，更有技术性一些的讨论：
还有一些非常有价值的长篇大论，分别讲了「后面再加测试的不可能性」（Later equals never）、「设计能力」、「一般编程方式与 TDD」一些方面。非常有价值。我觉得搬运的东西比我自己写的价值大多了，厉害的人好多。以下是不负责翻译版：
我觉得任何项目中，抱持着「我们以后再回去做某事」的想法，对项目来说一般都是风险，甚至危害。
我认为，这里面发生的了认知上的错觉。当我们在大脑里把工作推迟时，同时也把它所需的成本从方程中完全移除了。与其做一些当下肯定需要成本的事情，我们这样麻醉自己：这个事情放到后面做，应该就会简单一些，甚至到时就不需要任何开销了。
我们同时默认假设，到了以后，现状与外在环境会改变，因此面临的限制和压力相比当下也会减少。我们通常不知道这个以后是多久的以后。我们能知道的是，以后，我们就能专注在这些工作上，因此现在先推迟吧。
现实是，现状不会改变，外在环境也不会改变。当下有压力，到时也会有压力。你希望有一段时间，所有的交付压力都降低了，大家都能休息一下重构重构代码。这样的以后是不会发生的。并且，复杂度和成本会增加，而非降低。因为到了「以后」，上下文完全消失了，你必须重新回忆搜集，这是成本增加的来源之一。其次，推迟了的工作，会影响所有下游系统的实现，这同样增加了复杂度。想「撤销」这些已有的实现，同样增加了总的成本。
也即是说，推迟了的工作不太可能再被拾起；即便可能，那时再做的成本只是徒然增加了，而非你所想象的那样会减少。完成它更难了。
怎么样让别人意识到这个错误的认识假设呢？我发现，在后面的某个时间节点，带领大家做一些计划练习会有帮助。让大家试着自己去估算，推迟工作并在以后去完成的成本会有多少。引导大家去思考「重新搜集上下文」、「撤销已有实现」等工作的成本。估算完成以后，让团队自己估算，要重新捡起这些工作需要多少成本，需要什么环境才能办到。
我的经验是，做完这个练习的团队都会意识到，以后再做远比现在做的成本高得多，也因此，以后再做这个承诺实现的可能性比他们预想的要小得多。 - P.G.Moss
我从来无法理解，不写测试怎么可能快于写测试。比方说，我在写一个网页，为了验证我写的代码是否工作，难道我要启动整个 web 服务器、登录然后点很多下鼠标才能到我需要测试的页面去？
话虽如此，在我的经验中，要做好 TDD 是需要对软件设计有个基本认知的。我看到有些人写的测试简直疯狂，有给构造函数写测试的，有用反射来获取方法参数，以检验是否传入了正确的 lambda 函数的，诸如此类。
恕我冒昧地推荐一些资料： [GOOS 一书]() 以及（给我们所做的大部分的数据库操作）对 hexagonal 架构 的基本了解（最近 Alistair 本人有个专题视频），它们可能可以让你了解，为何远在90年代前人们就觉得，某种形式的 TDD 是必要的。是否测试先行，我觉得无所谓，我有时也会先写一些实现，再添加测试来覆盖。前提是，写测试前我就已经知道测试会长啥样了。背后真正重要的是，你需要小步前进。每当你写了一些产品代码，你总需要一个测试（或其他什么）来验证代码是否写对了。
PS. 邮件组里各位在讨论什么我其实没有全部读完，我看到的是，有人写了一些不好的代码，TDD 未能阻止他继续写不好的代码（或说促使他写得稍微好一些）。于是这老哥就说，TDD 根本没用，因为他觉得写（这样的坏）代码，不用测试根本快多了。 - J.Soeters
我表示十分理解，为什么人们不觉得 TDD 是一项可以让他们作为个人，工作更加高效的技术。
在我接触到真正把敏捷的这些工程实践（TDD、持续集成、结对编程，等等）做得很好的团队之前，我在其他的公司做了10年的软件开发。我是读了有关 XP（极限编程）的书，但实际工作中，我从未见过真正这样工作，或者知道怎样实践 极限编程 的人。
读 XP 的实践然后自己去摸索实践，是个非常痛苦的过程。通常实际的情况是，你当前工作的代码库有着混乱纠结的依赖，想写书本上介绍的那种简单纯净的测试，根本不可能。很多情况下，你自己连如何写简单的测试都不知道。不知道怎么用 mock，不知道怎么重构…确实，自己去探索，感觉反而更乱了，还不如马上把活干完。
倒腾到最后，就像对绝大多数的团队来说一样，你对这些实践也只是有所耳闻。你知道有这么个东西。它理论上听起来很棒。不过你觉得，在实际工作中，没几个人是这么做的。大多数人还是用他们所习惯的那种方式编程，并且日子如常，并没什么问题。 - K.Morris