创造性开发

Computing is a collaborative 协作 activity. Working in a team brings more perspectives 视角, catches more errors, and produces better programs than working alone. Good collaboration uses consensus building 达成共识, clear communication, and each member's strengths. Pair programming 结对编程 – two people at one computer, one typing and one reviewing – is a common practice. On the exam, you should be able to explain how collaboration improved a program (more ideas, fewer bugs 缺陷, wider testing 测试).

Worked example. Two students build a quiz app. Mei writes the scoring procedure while Tom reviews each line as she types; later Tom asks five classmates to try the app, and two of them find that a blank answer crashes it. How did collaboration help?

1. Tom's review caught errors as they were typed (pair programming).
2. The classmates are users with different habits; their tests found a case neither programmer had thought of, the blank answer.
3. Each benefit is named and tied to the program: "more testers found the blank-answer crash" earns credit where "teamwork is good" does not.

Every program is written for a purpose 目的 – it solves a problem or pursues an interest. A program takes input 输入, processes it, and produces output 输出. Inputs can come from a user, a device, a file, or another program; outputs can be visual, audible, textual, or a signal to a device. Being able to state a program's purpose, and describe its inputs and outputs clearly, is a core skill (and part of the Create performance task).

Worked example. A step-counter app reads movement from the phone's motion sensor, counts steps, and shows the day's total and a badge when the user passes 10,000.

A common mistake is to give the function as the purpose: "it counts steps" says what the program does, not the problem it solves.

Programs are built through an iterative 迭代的 process, not in one straight line: investigate the problem and users, design (often with a diagram 图示 or written plan), implement 实现 in code, and test – then repeat. A large problem is broken into smaller pieces (decomposition 分解). Comments 注释 and clear naming document the design so others (and your future self) can understand it. Development is incremental 增量的 – build and test a small piece, then add the next.

Investigating what users actually need

Before any code is written, the developer investigates the problem and the people who will use the program. Three ways to do that:

• surveys 调查问卷 sent to potential users, which collect data from many people quickly;
• interviews 访谈 and direct observation 观察 of users doing the task by hand;
• studying existing solutions to see what already works and what frustrates people.

The findings are turned into a design. Two artefacts do that: a program requirements 程序需求 list saying exactly what the program must do, and diagrams representing the layout of the user interface 用户界面 — sketches showing which controls appear where, and what each one does when used. Designing the interface on paper first is cheaper than discovering after coding that the buttons are in the wrong place.

Events, and programs that wait

Not every program runs straight through from top to bottom. An event 事件 is generated when a key is pressed, a mouse is clicked, a program is started, or any other defined action occurs — and an event changes the flow of execution 执行流程: the program pauses what it was doing and runs the code attached to that event, called an event handler 事件处理程序.

This is why a program with a graphical interface can appear to be doing nothing: it is waiting for the next event. The order in which those events arrive is decided by the user, not by the programmer, so the same program can run its blocks in a different order each time it is used.

A bug is an error in a program; debugging 调试 is finding and fixing it. Three kinds:

• a syntax error 语法错误 breaks the language's rules, so the program will not run;
• a runtime error 运行时错误 crashes the program while it runs (e.g. dividing by zero);
• a logic error 逻辑错误 lets it run but gives the wrong result.

Find bugs by testing with different inputs, adding print statements 打印语句 to see values, and hand-tracing 手动跟踪 the code. Choose the test inputs deliberately: they should demonstrate the different expected outcomes at or just beyond the extremes — the minimum and maximum values the program should accept, and a value just outside each of them. A program that works on ordinary data very often fails on an empty list, a zero, or a value one past the end of a range, so those are the inputs worth trying first. Fixing one bug at a time and re-testing is the reliable method.

Exam skill: be able to name the type of an error and describe a testing strategy that would catch it – a recurring multiple-choice and Create-task theme.

Worked example. A program meant to print the average of two numbers instead runs avg = a + b / 2. Tracing the order of operations 运算顺序, / runs before +, so it computes $a+\tfrac{b}{2}$ rather than the average. Add parentheses to fix it: avg = (a + b) / 2. Testing with $a=4,\ b=6$ confirms the fix — the buggy line gives $4+3=7$, the corrected line gives $\tfrac{10}{2}=5$. Testing with known inputs is exactly how you find and confirm a logic error.

• Assessment includes multiple-choice questions and the Create component, with written responses on the AP exam. Explain your reasoning clearly, not just your result.
• Know the benefits of collaboration and how diverse perspectives reduce bias in a program.
• Use precise vocabulary (iterative development, program requirements) when you describe a design process.
• Give and take feedback 反馈 constructively; credit collaborators and sources.
• Break a large problem into smaller modules that a team can build in parallel.