TDD 周报四「TDD 是一门艺术，不是科学」

[EthanLin-TWer]

让我们来走近艺术。这篇的话题是接着上篇 #177 ，其中提到了要做好 TDD，我们必须关注的两大方面，八大能力。这篇主要是围绕这其中的 TDD 和 tasking 能力建设展开的，主要精彩观点都来自仝校长，并感谢他支持我倒卖聊天记录…

前情回顾

TDD 的两大关键好处：效率 和 重构。前者作为高阶思维工具，使个人受益；后者作为代码质量的唯一保证，为团队所必须采用的实践。

为达此两大目标，有八种 能力/工具/意识 需要建设和优化：

• 写好测试的能力、对代码库技术栈架构分层的理解和编程能力、重构能力、设计能力
• 任务分解的能力、流畅的 todolist 系统、获取更快速反馈的能力、向更高阶思维的转变

这一套做下来，无数细节需要摸排熟悉。那么，作为 TDD 重要前件的「Tasking（任务分解）」，究竟应该怎样来做？怎样算是做得好？怎样能够不断获取反馈提高？你真的能够学习到你不知道的东西吗？

Unknown unknown

Hi 仝健。最近写了 一篇总结，里面辨识到围绕 TDD 有一些能力需要建设，比如 TDD 具体的练习方法、tasking 具体的方法等。在 编程的精进之道 里，你提及了一种方法 PDCA。不过感觉在实践中不一定有人能随时看你做，给予你及时的反馈，告诉你什么是好，什么是不好这样。想问，精进里提到的已经是全部呢，还是思沃学院这边在相关话题上有更详细的方法论和体系化的训练方式呢？

我觉得只能发现问题吧，总结下来也还是需要去请教的。因为出 action 这事会遭遇 unknown unknown。我最近在项目上尝试教练员-运动员模式的 pair，可以很好的提高，但是这个不太具备广泛推广意义。

这里面的两个关窍：时间 和 task。寻找时间花哪了，能不能通过抽象重新切分 task 让总时间变短。是两个思考的方向。第一点是指，在现有概念体系下的时间和流程优化；第二点纯指更抽象的整套概念体系，让思考速度更快，问题更简单。但这两个方向都会遇到 unknown unknown。

举一个不恰当的例子， jQuery -> Angular，就属于改变了整套概念体系，你的 tasking 列表完全不一样。

哎，unknown unknown 是不是指，「我并不能知道我所不知道的事」？就是说我 retro，我只能 retro 出我已经识别出的模式，并尽量提高这些 task 上的时间耗费，但我很难知道我所不知道的模式。太对了，学习时候总是有这个困惑。

对，你可以通过逐渐逼近，以及创新算法之类的启发式方法帮你想到一些思路，然而很有可能是把前人的道路再走一遍，很容易浪费时间。

那么问题域又有两个：「如何知道我所不知道的事情」？以及「在我所研究的领域下（如 TDD、特定技术栈的开发），前人都已经走过了哪些路」？初衷想向思沃学院请教的就是这第二个问题。就是说，在我们探索的过程中，已经摸索出了哪些初入门的同学 unknown 的问题？它们是不是学习过程中普遍会遇到的问题？比如「快捷键」、「live template」就已经是被我们挖掘出来的东西。我们有没有一份较为详细的文章或列表，记录这些问题，以供刻意练习呢？

有一些，不过还没仔细总结。我们有集合训练营，练习集合操作，有 REST API 训练营，练 API 增删改查，有字符串训练营，练习对某语言输出的预判。还有一堆 dojo 练习结构化拆解任务。不过还没考虑过在公司内做，因为觉得可能很多人不需要。

• https://github.com/orgs/tws-practice/dashboard
• https://github.com/tws-practice
• https://github.com/tws-practice-archive

Tasking 的极限在于你的概念模型

恩恩，大概理解，就是说针对「前端问题解决」这个问题域，新思维模式和框架的推广，使得我们完成这个目标的思维方式变了。tasking list 自然不一样了。所以，tasking 是随着特定问题域的现状和发展而改变的。

tasking 受制于你的概念模型。

也就是说，我可以通过训练，让思维更严谨，tasking 准确度越高，但是它的极限是受制于它的概念模型本身的。

对。tasking 的极限是受制于概念模型本身的。所以我们强调概念性思考作为我们的 Lead 的 Competence。

👍 理解又多了一些。结构化拆分任务我觉得也是我现在实践过程遇到的问题，就是说 tasking 的目标是「完全、穷尽、独立」，但达到这个目标的过程，有没有其他的套路？比如你字面上说的「结构化」。

结构化是按照程序的结构来设计 task。我在《编程的精进之道》后面的《像机器一样思考》第四 篇文章里写其实是有点问题的，按照结构来设计 task 不符合 TDD。最近正准备改，但是改完就觉得太艺术了，暂时没想到好思路改。

按结构就是按照程序代码的结构，还有一种视角是，场景化。就是测试的视角，那就是 TDD 了。

实践起来，发现如果单纯应用 TDD 场景视角出发的角度，tasking 可能看起来很完备，但实现起来根本与现有技术栈的架构和结构不符。那就是你所说的，tasking 是受制于你的概念模型的，在实践中还受制于具体代码库的架构结构。场景化地应用 TDD，要求对技术深入了解，并有一个与之互相流畅配合的 tasking list。

场景化思考不需要考虑架构。你站在用户的角度看问题的时候，用户是有固有模型的。你只能适应他的模型，不管你里面啥样。这才是 TDD 带来的思维的改变，你主要是写测试，实现是送的。

TDD 是艺术，不是科学

我能理解到 tasking 是受制于技术的概念模型的，不过又有一个问题：就是我的场景化思考可能是完备的，但变成测试用例，从 业务场景 到 具体实现这个转变过程中，我还能保证这些场景变成一条条 AC，变到技术的实现上依然是完备的吗？会不会由于技术架构的限制，导致我 task 出来的 list 从技术实现上根本无法完备等价地描述我的场景？

首先你要把业务场景穷尽，然后你的 tasking 才能出来。然后，task 实际上是基于你的概念模型和业务场景的一个平衡。如果缺了业务场景，写出来的 task 也会瘸腿，设计出的模型也可能是有害的。而 AC 就是场景的验收视角。

所以我们讲 TDD，其实其前置步骤：业务场景穷尽、平衡了概念模型和业务场景的 tasking list，是实施质量的两个重要前提。

对，所以它是一门艺术。而不是科学。因为穷尽场景这件事，是做不到的。

看过 SICP 么？很多问题人家都讲完了。自己就不要重新探索一遍了，人生苦短，多做点更有意义的事情。那本书真的是字字珠玑，每个练习都值得做一遍。那本书基本上讲清楚了，编程到底是一件什么事情。换句话说，你在编程这件事情上想清楚了，其他的业务领域你也就都想清楚了。因为在编程这件事上，套路一共就这么几种。抽象的看，你就穷尽了。

竟然能达到穷尽的地步。

抽象的看是可以的。这倒不完全是作者多么牛，而是人脑可能也就只能做到这个程度吧……

所谓的各个领域相通，各个技术相通，万法相通，背后是一个悲剧的事实：人脑就是这么弱鸡，人脑的运作本身就这么几种。

Conclusion

总的来说，校长解答了我这几个疑问：

• TDD/Tasking 目前没有标准化的灵丹妙药。探索的道路上，只能自己发现疑问，然后多去向他人请益。由于这个过程，会遇到 unknown unknown 的问题，建议多与他人交流，尽早获得反馈，及时调整
• TDD 的红绿循环已然是实施阶段了，在这之前有两个极为重要的事要做：穷尽业务场景、列出平衡了业务场景和技术架构的 tasking 方案
• tasking 方案这件事，本质上是一个取舍和平衡，正是 dev 水平能力的体现，没有标准答案。它是艺术，不是科学，无法模板化传授
• 具体到 tasking 这件事，它是受制于你当前用于解决问题的概念模型的。所谓优化 tasking，极限也只是往这个概念模型的极限在逼近
• 那么效率提高，主要两个思路：现有概念模型下的优化、寻找更抽象的概念体系

从这个角度上讲，我一直提 Declarative Mac，其实是强调思维模型上的转变。

有一个问题没有解决，「如何知道我不知道的事」。仝健没有提及专门的解决方案，只是提多了解前人已经干了什么工作，及早学习不要自己重新走一遍。代领导说，这本身也是一个问题，符合常规问题的解决思路。比如你不知道，你就搜嘛，搜这个问题是什么，现状如何，一般有什么解决方案。

在高阶编程、概念模型、更有成效的程序员这些话题上，已经有很多材料。现在前端博文，多没看到有触及这个领域。接下来可看看，如《SICP》、《桌有成效的程序员》等。

Reference

• 编程的精进之法
• 像机器一样思考（一）—— 宏观的基础
• 像机器一样思考（二）—— 数据的细节
• 像机器一样思考（三）—— 穷尽就是力量
• 像机器一样思考（四）—— 一图抵千言
• 像机器一样思考（五）—— 第一个应用
• 像机器一样思考（六） —— 脑中的重构
• 像机器一样思考（七） —— 跨应用思考

---

2017.06.18

在 Lenovo 加班蹭网的日子

[EthanLin-TWer]

似乎主要的框架已经被说完了。

[JimmyLv]

Finally, learn from book > 把前人的道路再走一遍，很容易浪费时间。

[EthanLin-TWer]

https://blog.linesh.tw/#/post/2017-06-18-tdd-series-4-tdd-is-an-art-not-scientific

有博客就是好。