Creative Development
AP Computer Science Principles Topic 1 5:03 English narration · English + 中文 subtitles burned in
Chapters
Transcript
Here is a program that should print the average of two numbers.
这是一个本该打印两个数平均值的程序。
It runs. It does not crash. It prints an answer — and the answer is wrong.
它能运行，不会崩溃，也确实打印出了一个答案—— 而这个答案是错的。
Give it four and six and it prints seven, when the average is five.
给它四和六，它打印七，可平均值是五。
Nothing is broken in the grammar; the computer did exactly what you wrote.
语法上什么都没坏， 计算机完全照你写的做了。
That is a logic error, and it is the reason a program is never finished until it has been tested.
这就是逻辑错误， 也正是"一个程序在被测试之前永远不算完成"的原因。
Welcome to Unit One. How programs get built: with other people, on purpose, one small piece at a time, and tested until the bugs are gone.
欢迎来到第一单元：程序是如何被造出来的——和别人一起、带着明确目的、 一次一小块地做，并且一直测试到 bug 消失为止。
Let's begin.
让我们开始吧。
Computing is a collaborative activity that uses consensus building, and the exam treats that as content, not decoration. Three things a team gives you that working alone cannot.
计算是一项协作活动，靠的是建立共识，而考试把这当作正式内容，不是点缀。
More perspectives, which reduces bias in what the program assumes about its users. More eyes, which catches more errors. And wider testing, because different people try different inputs.
团队能给你三样独自工作得不到的东西：更多的视角， 这会减少程序对用户所做假设中的偏见；更多双眼睛，能发现更多错误； 以及更广的测试，因为不同的人会尝试不同的输入。
Pair programming is the standard practice: two people at one computer, one typing and one reviewing as it is written.
结对编程是标准做法：两个人共用一台电脑，一个人敲代码，另一个人边写边审查。
And when the exam asks how collaboration improved a program, name a specific benefit — do not just say the team worked well.
而当考试问"协作如何改进了这个程序"时，要说出具体的好处， 不要只说"团队合作得很好"。
Every program has a purpose: it solves a problem or pursues an interest.
每个程序都有一个目的：解决一个问题，或者满足一种兴趣。
And every program, however large, decomposes into the same three stages — input, processing, output.
而每个程序，无论多大，都可以分解成同样的三个阶段——输入、处理、输出。
Inputs can come from a user typing, from a device such as a sensor, from a file, or from another program.
输入可以来自用户的键盘、来自传感器之类的设备、来自文件，或者来自另一个程序。
Outputs can be visual, audible, textual, or a signal that makes a device act.
输出可以是图像、声音、文字，或者是让某个设备动作的信号。
Being able to state a program's purpose and describe its inputs and outputs precisely is a core skill, and it is marked directly in the Create performance task.
能准确说出一个程序的目的、并描述它的输入和输出，是一项核心技能， 而且在 Create 任务里是直接给分的。
Now, how a program actually gets built — through an iterative process, not a straight line.
现在讲程序实际是怎么造出来的——通过迭代过程，而不是一条直线。
You investigate the problem and the people who will use it. You design, often as a diagram or a written plan. You implement it in code.
你先调研问题，以及将要使用它的人；然后设计，通常画成图或写成计划； 接着用代码实现。
Comments document the design so others can understand it.
注释记录设计，好让别人也能看懂。 然后测试。
Then you test. And then you go round again, because testing always tells you something you did not know.
之后你再绕回去 重来一遍，因为测试总会告诉你一些你原本不知道的事。
Two words describe the shape of this. Decomposition: break a large problem into smaller pieces a team can build in parallel. And incremental: build one small piece, test it, and only then add the next.
有两个词描述这个过程的形状： 分解——把一个大问题拆成小块，让团队并行地做； 以及增量——先做一小块并测试它，然后才加下一块。
A bug is an error in a program, and debugging is finding and fixing it.
bug 就是程序里的错误，而调试就是找到并修好它。
There are exactly three kinds, and the exam wants you to name which one you are looking at.
错误恰好分三类， 考试要求你能说出眼前是哪一类。
A syntax error breaks the language's rules, so the program will not run at all.
语法错误违反了语言的规则，程序根本跑不起来。
A runtime error crashes the program while it is running — dividing by zero is the classic one.
运行时错误在程序运行过程中让它崩溃——除以零就是最典型的例子。
And a logic error lets it run all the way to the end and gives you the wrong result.
而逻辑错误会让程序一路跑到结束，然后给出错误的结果。
Notice the pattern: the earlier the error is caught, the cheaper it is.
注意这个规律： 错误被发现得越早，代价就越小。
The logic error is the dangerous one, because nothing warns you.
逻辑错误是最危险的那一种，因为没有任何东西会警告你。
Four ways to find a bug, and you should be able to describe them.
找 bug 有四种方法，你应该能描述出来。
Test with different inputs, and deliberately include edge cases — zero, an empty list, the largest allowed value.
用不同的输入测试， 并且刻意包含边界情况——零、空列表、允许的最大值。
Add print statements so you can see what the variables actually hold.
加上打印语句， 好让你看见变量里实际装的是什么。
Hand-trace the code, writing each variable's value down as you step through — that is a trace table.
手工走查代码，一步一步把每个变量的值写下来—— 这就是追踪表。
And read it aloud to another person, which is why pair programming works.
再有就是念给另一个人听，这正是结对编程有效的原因。
Then one rule for fixing: change one thing at a time and re-test.
修复时有一条规则：一次只改一处，然后重新测试。
Fix two bugs at once and you will not know which change worked.
一次修两个 bug，你就不知道到底是哪个改动起了作用。
Back to our broken average.
回到我们那个坏掉的平均值。
Trace the order of operations. Divide runs before add, so the line computes a, plus b over two — not the average at all.
追踪一下运算顺序：除法先于加法执行， 所以这一行算的是 a 加上 b 的一半——根本不是平均值。
Add brackets around a plus b, and now the addition happens first.
在 a 加 b 外面加上括号，现在加法先执行了。
Test it with known numbers: four and six.
用你已经知道答案的数来测试：四和六。
The buggy line gives four plus three, which is seven. The corrected line gives ten over two, which is five.
有 bug 的那一行给出四加三等于七；改正后的那一行给出十除以二等于五。
Testing with inputs whose answer you already know is exactly how you confirm a logic error is gone.
用你事先就知道答案的输入去测试，正是确认逻辑错误已被消除的方法。
Three marks students throw away.
三个学生常丢的分。
First, when a question shows you a bug, name the type of error — syntax, runtime or logic — and then describe a test that would catch it.
第一，题目给你一个 bug 时， 要说出错误的类型——语法、运行时还是逻辑——然后描述一个能抓住它的测试。
Second, most of this course is assessed by written and Create tasks, so explain your reasoning, not just your result; the marks are for the why.
第二，这门课大部分通过书面任务和 Create 任务来考核， 所以要解释你的推理，而不只是给出结果；分数是给"为什么"的。
Third, when you write about collaboration, give a specific benefit — more perspectives reduced bias, or wider testing found an edge case — rather than saying the team worked well together.
第三，写到协作时，要给出具体的好处——比如更多视角减少了偏见、 或者更广的测试发现了一个边界情况——而不是说"团队配合得很好"。