Stream of Consciousness Driven Development

<p>这是上周我刚刚尝试的一个方法，但它似乎很有潜力，值得在未打磨的情况下展示出来。当时我正在与一位客户结对编写一份规范。我发现了规范中的一个问题，以及一种复杂的修复方式。与其试图口头解释，我首先创建了一个新的markdown文件：</p> <div class="codehilite"><pre><span></span><code>NameOfProblem.md </code></pre></div> <p>然后我开始打字。先是问题摘要，然后是详细描述，接着是解决方案及其可行的原因。当我的搭档提出问题时，我将他的问题以及我们的讨论融入了整个流程。如果解决方案走进了死胡同，我们就将其标记为死胡同。最终文件看起来像这样：</p> <div class="codehilite"><pre><span></span><code>Current state of spec Problems caused by this Elaboration of problems What we tried that didn&#39;t work Proposed Solution Theory behind proposed solution How the solution works Expected changes Other problems this helps solve Problems this does *not* help with </code></pre></div> <p>只有当这一切完成后，我的搭档完全理解了思考链，<em>并且</em>我们一致认为这是正确的方法，我们才开始对规范进行修改。</p> <h3>这比直接进行更改好在哪里？</h3> <p>这个更改在<em>概念上</em>是复杂的。一个粗略的类比：想象一下与一位初学者结对，他写了一个插入排序，而你想用快速排序替换它。你需要解释为什么插入排序太慢，为什么快速排序不慢，以及快速排序如何正确地对列表进行排序。这可能会涉及到计算复杂性、大O表示法、递归等话题。这些都是你已经内化的概念，所以更改对你来说很简单，但解决方案使用了初学者不知道的概念。因此对他们来说，这在概念上是复杂的。</p> <p>我并非与一位初学程序员或初学规范编写者结对。这是一位能够自信地独立编写复杂规范的客户。但他们不像我这样全职从事规范工作。任何结对中存在经验差距时，有些解决方案对一个人来说概念上简单，对另一个人来说则复杂。</p> <p>我经常注意到，当一个人不完全理解更改背后的概念时，他们就会说“你是专家，我相信你”。这最终会导致一个完全无法维护的规范。因此，全部写出来。</p> <p>正如我之前所说，我只尝试过一次（尽管我在教学研讨会时成功使用过类似的想法）。不过效果还不错！只是要做好大量输入的准备。</p>