# 总-课程目标

Hey，你好，我是吕靖，欢迎来到「前端 TDD」的实战训练营，接下来我们即将共同度过 21 天的极限编程冒险之旅。在此之前，让我来给你做一个简要的介绍，顺便打打鸡血。

## 极限编程，测试驱动开发

我们清晰地看到，在中国的 IT 行业，已经有一批打着“敏捷”大旗、却回避敏捷最核心的开发技术实践的“[中华田园敏捷](https://www.zhihu.com/question/328042540)”实践者和传播者。有鉴于此，我们认为，有必要旗帜鲜明地重申敏捷软件开发的一些最为根本的原理：

* 缺少**可重构性**的软件，不可能快速响应变化。
* 没有高覆盖率、快速运行的**单元测试**，重构就不可能落地。
* **测试驱动开发**是获得高质量单元测试集的唯一有效方法。
* 建立在充分覆盖且运行快速的自动化测试基础上的**持续集成**是迭代式开发的必要条件。

> 摘自 [eXtremeProgramming.cn](http://www.extremeprogramming.cn/content/about-us.html)，**极限编程**是唯一将开发技术实践提到核心地位、并围绕开发技术实践构建起完整软件交付流程的敏捷方法论。

## 以终为始，你会得到什么？

让我们先来谈谈你的目标，Where are we going?（我们要到哪儿去？）以终为始，从最终的目标开始思考需要什么样的条件，然后主动想办法去创造条件从而达成问题的解决。与管理者结果导向的思维有所不同，我们作为技术思维者可能往往是被动地在等待条件成熟。

技术人员的思维是直线式思维，由始到终，就是从已知条件推导出结果，一旦已知条件项缺少时，就无法推出结果，我们就会很焦虑。作为一名程序员，如果你发现自己很焦虑，很可能是你的程序猿思维在作祟。

那么，我们在学习这门课程之后，你会掌握什么样的编程技能呢？

* 以终为始：每次编码明确需求目标，明晰用户行为验收路径；
* 任务分解：实例化需求产出测试用例，框定需求范围减少浪费；
* 自动化测试：让机器给予你最及时的反馈，提供功能回归保障；
* 持续重构：调整程序代码改善软件的质量、性能，快速响应变化。

上边儿列出来的几点，也是我想让你真正掌握的几个思考原则。但终究是需要靠你，靠你自己的实战练习，来承载这些技能。所以说，我自己也是在采用以终为始的方式在思考：不是说**我**掌握了什么东西，然后把它们都讲出来；而是在**你**学习过后，期望怎么样去改变**你**的工作方式？

## 除机心，刻意练习

> 传说孔子的学生子贡 ，在游楚返晋过汉阴时，见一位老人一次又一次地抱着瓮去浇菜，“搰搰然用力甚多而见功寡”，就建议他用机械汲水。老人不愿意，并且说：“有机械者必有机事，有机事者必有机心。吾非不知，羞而不为也。” 子贡满面羞愧，低下头去不能作答。

「有机械者必有机事，有机事者必有机心」。这里的「机心」其实指的就是巧诈之心，机巧功利之心。人类聪明就在于会用工具，但容易犯的错误就是，**只**会用工具。

我期望你不再迷信于“学习”某个课程，或者是使用某个前端框架、IDE 等工具或方法论，而是去“练习”整个课程项目。本次实战营区别于其他所谓的知识付费课程，重在刻意练习。

获得技能的唯一方式，是通过**刻意练习**。刻意练习有以下几个特点：

* 刻意练习必须**大量重复**。将新的技能练成肌肉记忆，方能在实际工作的压力下运用自如。
* 刻意练习必须**保持专注**。集中一段时间专门练习一项技能。散落在日常工作中的、不时被打断的练习，无法产生好的效果。
* 刻意练习必须**在学习区进行**。在“舒适区”的练习无法增进技能，在“恐慌区”无法开展有效练习，只有在两者之间的“学习区”开展练习才有价值。
* 刻意练习必须**有及时反馈**。教练和同伴在每次练习后立即反馈，纠正错误的动作，强化正确的动作。

实战营所有的实战项目就是帮助你练习的过程，需要你死磕自己，持续做工。反复的练习也是为了让你在日常工作中真正运用这项技能，帮助你提高效率。相比之下，我更希望你能在实际工作能够用到课程中的某个练习点，“哦，原来我在实战训练营中练习过”，那才是真正有用的。

## 游戏化，积极反馈

> 现实已经破碎，而我们需要创造游戏来修复它。—— 《游戏改变世界》

与此同时，我也期望用游戏化的方式让整个训练营变得更加有趣，让你学习起来更有动力，也让大家在整个练习能够共同陪伴。

与游戏相比，现实毫无生产力。在进行机械性重复任务的时候，人的动力大都来自奖励机制。但是一旦需要创造性思维，奖励和惩罚却会在现实中导致更差的表现。而自主（autonomy）、专精（mastery）和意义（purpose）才是解决复杂问题的动力。结合游戏化，我们的前端 TDD 实战营能够带给你：

* 更满意的工作：自主（autonomy）体现为掌控感，当你有权决定自己的工作时间、工作内容、工作方式的时候，人们天生都是积极行动、乐意付出的。任务分解，意味着沉浸在有着清晰定义、能看到直接努力结果的满意工作当中。全情投入当下，这是游戏化的参与机制。
* 更有把握的成功：专精（mastery）是一种心态，认为事情总是有改进的空间。我们对成功的机会总是保持乐观态度，随着时间的推移，让自己越来越好。你可以在各方面取得进步，不论是弱项还是强项。这要求你付出努力，刻意训练。专精经常让你体验到「心流」的美妙感觉。面对的挑战与自身能力完美匹配，及时反馈，不断的重构优化。游戏中的实时反馈，就是游戏化的激励机制。
* 更强的社会联系：我们渴望与社会建立联系。人是极端的社会生物，哪怕是最内敛的人，也有很大一部分幸福来自与心爱的人共度美好时光。我们渴望分享经验，建立纽带，一起完成所有人都看重的事。和游戏相比，现实是疏离的。游戏建立了更强的社会纽带，创造了更活跃的社交网络。我们在社交网络用于互动的时间越多，越有可能产生一种积极的“亲社会情感”。实战营微信群的陪伴，让我们和陌生人结盟，创造更强大的社群。
* 更宏大的意义：意义（purpose）会带来幸福，而它本身就是一种比幸福更强的驱动力。你想让自己做的事情有意义，想要把事情做好，渴望过得有意义，渴望成为超越自身的宏伟事业的一部分。最重要的是，我们希望能投入某种超越个人生活、能产生持久影响的事情中去，并为之做出贡献。

我们认为，重新认识并学习极限编程，是中国 IT 业补齐技术根底、打牢软件基础、并真正走上敏捷道路的必要环节。为此，我们自发地组织起来，为推广极限编程尽绵薄之力。这也是我在开发这个实战营所牢记的使命感，帮助中国的 IT 组织更好地了解和采用极限编程，切实地打好软件开发的能力基础。

其实，让幸福成为一种习惯，不管你是热爱编程与否，你都是在优化自己的效率，让自己有更多的时间陪老婆孩子，或者是追寻自己内心真正想要的东西。游戏化让我们更容易接受好的建议，并尝试培养更快乐的习惯。好的游戏具有强大的力量，能永远地改变你看待自己和自身能力的方式。

## 响应变化，适应性计划

> 预测型计划适合打靶子，适应性计划适合猎豹子。 —— 李小波

上帝掷骰子吗？也许从微观上来说，量子力学告诉我们本质上世界就是随机的。今天的商业 IT 环境用一个词就可以概括：不确定。不确定带来颠簸和变动，不确定滋生怀疑和恐惧。回到软件开发这个话题，我想跟你来谈一谈「响应变化」，特别是在前端领域。

![敏捷之 Adaptive Planning](/files/-M0fdPAAEzFlG3atVyoW)

上图来自敏捷宣言签署人之一的 Martin Fowler，提到了预测型计划和适应性计划：

1. 瀑布开发是典型的预测型计划，跟敏捷没有任何关系；
2. 但是，迭代开发也不等于敏捷，它也可能包含预测型计划；
3. 所以，不是做了适应性计划就是敏捷，而是聚焦价值，持续改进，「以人为本」。

预测型计划：传统的计划方式，典型的表现形式是甘特图，提前计划好什么时间做什么事情，A 依赖 B，B 就要放在 A 的后面。

适应性计划：环境越不确定，越需要边走边看，这时过于详细的计划，就是浪费。较好的做法是，做一个比较粗的计划，把近期的计划做细一点，然后定期去回顾并调整计划。

前端嘛，UI 嘛，你也都知道，相对于其他分工，变化其实是很多的，比如说需求的变化或者是设计的变化甚至是 API 少了个字段这样的变化。我们应当如何去应对这样的变化？

![API 少了个字段](/files/-M2gGz7YqeVg9reqHvDM)

当然，我是期望你不要把自己局限于某个框架、或者是某个前端分工之上，因为本质上，软件开发是一项知识消费的活动，目的是消除知识壁垒；跟传统行业想要的分工带来效率提升的结果不同，后者因为存在其明显的知识壁垒，术业有专攻才能在不知道相关的知识、或不需要知识传递的前提下提高效率。更多内容可以查看[软件开发行业的第一性原理](https://mp.weixin.qq.com/s/qYvI2_K8m4FwTqGaMMjTdQ)。

## 重要的事情多迭代，紧急的事情先迭代。

无论上边儿我们说整个商业环境如何变化，以及互联网软件开发如何响应变化，但具体的来说最终还是要落实到我们开发者身上，毕竟我和你都还是要写代码的嘛。「以人为本」，目光拉回到我们自身，个人该如何应对这些来自外部的变化呢？

你可以记住这样一句话，我们不是为了在前端领域解决开发效率的问题，而是在整个软件开发工作中提高效率。

当然咯，在推广到整个团队之前，我期望你自己能够掌握这一整套的方法论。这套方法背后的思想其实也是可以运用在个人领域的，我希望你把优先级定好，找出自己真正想做的事情，然后也分享一下我做事情的原则：

重要的事情多迭代，紧急的事情先迭代。

当然，这句话是有前提的，就是 MVP（Minimum Viable Product），即最小可行性产品，基于 MVP 再持续迭代。敏捷精益的工作方法也可以运用到你的个人目标：“最小可行性”、“持续迭代”。当你面对一项任务的时候，先出一个“最小可交付”的版本寻求对方的反馈，然后进行迭代，一次比一次做得更好。

![iteration on things](/files/-M0hAbMGw7VFAhQKAhJA)

我希望你基于这样的原则，能够反复的去练习，刻意练习。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://jimmylv.gitbook.io/tdd-frontend/01-goal.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.