A-Level Computer Science: Practical Approaches to Writing Maintainable Programs | A-Level计算机：编写可维护程序的实践方法

📚 A-Level Computer Science: Practical Approaches to Writing Maintainable Programs | A-Level计算机：编写可维护程序的实践方法

Maintainable code is code that can be easily read, understood, modified, and debugged by others — or by yourself, months after you wrote it. In A-Level Computer Science, examiners expect you not only to write working code, but also to demonstrate structured, clear, and maintainable practices.

可维护的代码是指能够被他人——或者几周后重新阅读的自己——轻松阅读、理解、修改和调试的代码。在A-Level计算机科学考试中，考官不仅期望你编写能运行的代码，还期望你展示结构化、清晰、可维护的编程实践。

---

1. Understanding Maintainability | 理解可维护性

Software maintenance often consumes more than 70% of a system’s lifetime cost. Maintainability is the degree to which a program can be updated with minimal effort, minimal risk, and minimal disruption.

软件维护通常占据系统生命周期成本的70%以上。可维护性是指以最小工作量、最小风险、最小干扰来更新程序的程度。

Key indicators of maintainable code include:

可维护代码的关键指标包括：

• Readability — a human reader can follow the logic quickly.
• Readability（可读性） —— 人能够快速理解程序逻辑。
• Modifiability — changing one behaviour does not break unrelated parts.
• Modifiability（可修改性） —— 修改某一行为不会破坏无关部分。
• Testability — automated tests can target small units easily.
• Testability（可测试性） —— 自动化测试能够轻松地针对小单元进行。
• Documentation — comments and external docs explain ‘why’ behind decisions.
• Documentation（文档） —— 注释和外部文档解释决策背后的”为什么”。

---

2. Modular Design | 模块化设计

Modularity means breaking a large problem into smaller, independent sub-problems, each implemented as a function, procedure, or class. Each module should have a single, clear responsibility.

模块化意味着将大型问题分解为更小的、独立的子问题，每个子问题以函数、过程或类的形式实现。每个模块应只有单一的明确职责。

Example — instead of one giant block of code, separate user input from processing from output:

例如——不要使用一个庞大的代码块，而是将用户输入、处理和输出分开：

validate_input() → calculate_result() → format_output()

Benefits of modular design:

模块化设计的优点：

• Each module can be tested in isolation.
• 每个模块可以独立测试。
• Reuse across projects is easier.
• 跨项目复用更加容易。
• Debugging: a fault is localised to a small area.
• 调试：故障被限制在局部区域。
• Team development: multiple programmers can work in parallel.
• 团队开发：多个程序员可以并行工作。

---

3. Meaningful Naming Conventions | 有意义的命名规范

Names should describe purpose, not type. For instance, student_score is better than x. Choose a consistent style — camelCase or snake_case — and apply it everywhere.

名称应描述用途，而非类型。例如，student_score 比 x 更好。选择一致的风格——camelCase（小驼峰）或 snake_case（下划线命名）——并始终如一地应用。

Guidelines:

准则：

• Use verbs for functions: calculateAverage(), findMax().
• 函数使用动词：calculateAverage()、findMax()。
• Use nouns for variables and objects: total_marks, student_list.
• 变量和对象使用名词：total_marks、student_list。
• Boolean variables use is, has, can: is_valid, has_completed.
• 布尔变量使用 is、has、can：is_valid、has_completed。
• Constants are usually UPPER_CASE: MAX_SIZE.
• 常量通常使用全大写：MAX_SIZE。
• Avoid abbreviations like cnt unless standard.
• 除非是标准缩写，否则避免使用 cnt 这类缩写。

Poor naming forces readers to trace every line; good naming makes the code almost self-documenting.

糟糕的命名迫使阅读者逐行追踪；良好的命名使代码几乎可以自我解释。

---

4. Comments and Documentation | 注释与文档

Comments should explain why, not what. The code already shows what it does. A comment such as // increment i adds no value. Instead, describe the intention or a non-obvious constraint.

注释应解释”为什么”，而非”做什么”。代码本身已经展示了它做什么。像 // increment i 这样的注释毫无价值。相反，应描述意图或非显而易见的约束。

Useful comment examples:

有用的注释示例：

• // Use Haversine formula because Earth is a sphere
• // 使用Haversine公式，因为地球是球体
• // O(n log n) — required for real-time response
• // O(n log n)——满足实时响应要求

For larger programs, add a file header comment: author, date, purpose, and version. Also document module interfaces: parameters, return values, and possible errors.

对于较大的程序，添加文件头注释：作者、日期、用途和版本。同时记录模块接口：参数、返回值和可能的错误。

---

5. Indentation and Code Layout | 缩进与代码布局

Consistent indentation visually reveals the program’s control structure. In Python, indentation is required; in other languages it is still expected style.

一致的缩进在视觉上揭示了程序的控制结构。在Python中，缩进是必需的；在其他语言中，这也是公认的规范风格。

Use 2 or 4 spaces per level — not tabs mixed with spaces. Also keep lines short (e.g. under 80–100 characters) to avoid horizontal scrolling.

每级缩进使用2或4个空格——不要混用制表符和空格。同时保持单行代码较短（例如80–100字符以内），以避免水平滚动。

Compare these two versions:

比较以下两个版本：

if valid: process() else: reject()

if valid:
  process()
else:
  reject()

The second version makes the branching structure explicit and immediately readable.

第二个版本使分支结构清晰明确、立即可读。

---

6. Avoid Duplicate Code (DRY) | 避免重复代码（DRY原则）

DRY — Don’t Repeat Yourself. Duplicated code multiplies maintenance effort: a bug fixed in one copy may remain in another. Extract common logic into a function or a constant.

DRY——不要重复自己。重复代码成倍地增加维护工作量：在一个副本中修复的bug可能残留在另一副本中。将公共逻辑提取到函数或常量中。

Example: instead of writing the same discount computation three times, write once:

示例：与其三次编写相同的折扣计算，不如编写一次：

def apply_discount(price, rate):
  return price × (1 − rate)

Then call this function from all three places. If the formula changes, only one edit is required.

然后从这三个地方调用该函数。如果公式改变，只需要修改一处。

DRY also applies to data: use a single constant for fixed values instead of retyping literals everywhere.

DRY原则同样适用于数据：为固定值使用单一常量，而不是到处重新输入字面量。

---

7. Use Constants for Magic Numbers | 使用常量替代魔法数字

Raw numeric literals embedded in code — such as 0.07 for a tax rate — are called magic numbers. They are hard to understand and easy to mistype.

嵌入在代码中的裸数字字面量——例如税金率的 0.07——被称为魔法数字。它们难以理解且容易打错。

Instead, define named constants:

相反，定义具名常量：

TAX_RATE = 0.07
total = subtotal × (1 + TAX_RATE)

Advantages:

优点：

• Meaning is communicated by the name.
• 名称传达了含义。
• If the tax rate changes, only one line needs editing.
• 如果税率变化，只需要编辑一行。
• Typing errors are more likely to be noticed.
• 打字错误更容易被察觉。

---

8. Robust Error Handling | 健壮的错误处理

Maintainable programs anticipate errors — invalid input, missing files, network drops — and respond gracefully instead of crashing.

可维护的程序会预见错误——无效输入、文件缺失、网络中断——并以优雅的方式响应，而不是崩溃。

Good practices include:

良好的实践包括：

• Validate all external inputs before processing.
• 在处理之前验证所有外部输入。
• Use exception handling (try-except in Python, try-catch in Java).
• 使用异常处理（Python中的try-except，Java中的try-catch）。
• Handle each specific exception type separately, not one generic catch-all.
• 单独处理每种特定异常类型，而不是一个笼统的捕获所有异常。
• Provide useful error messages containing the actual cause.
• 提供包含实际原因的有用错误信息。
• Clean up resources (close files, network connections) even when errors occur.
• 即使在发生错误时也要清理资源（关闭文件、网络连接）。

Example — reading user input safely:

示例——安全地读取用户输入：

try:
  n = int(input())
except ValueError:
  print(“Please enter an integer.”)

---

9. Testing for Maintainability | 面向可维护性的测试

Tests protect maintainability by catching regressions when someone modifies code. A small set of automated unit tests gives confidence that refactoring does not break existing behaviour.

测试通过捕获代码修改时的回归问题来保护可维护性。一小组自动化单元测试能让程序员确信重构不会破坏现有行为。

Key testing strategies:

关键测试策略：

• Test boundary values: empty input, maximum size, negative numbers, zero.
• 测试边界值：空输入、最大尺寸、负数、零。
• Test normal cases and intentionally invalid cases.
• 测试正常情况和故意无效的情况。
• Use descriptive test names: test_apply_discount_with_zero_rate().
• 使用具有描述性的测试名称：test_apply_discount_with_zero_rate()。
• Keep tests independent — each test should not depend on another test running first.
• 保持测试独立——每个测试不应依赖另一个测试先运行。

Well-tested code is easier to extend because you can verify that new features do not break old ones.

经过良好测试的代码更容易扩展，因为你可以验证新功能不会破坏旧功能。

---

10. Version Control | 版本控制

Version control systems (e.g. Git) are essential for professional and maintainable software. They track every change, allow you to revert to previous versions, and support collaborative workflows.

版本控制系统（例如Git）对于专业且可维护的软件至关重要。它们记录每一次更改，允许你回退到之前的版本，并支持协作式工作流程。

Essential habits:

必要习惯：

• Commit regularly with clear messages: fix: correct tax calculation for non-residents.
• 定期提交并附上清晰的提交信息：fix: correct tax calculation for non-residents。
• Commit one logical change at a time.
• 一次提交一个逻辑变更。
• Use branches for new features or experiments.
• 使用分支进行新功能开发或实验。
• Write a README that explains how to build, run, and test the project.
• 编写README，说明如何构建、运行和测试项目。

In an exam context, you will not use Git, but you should be able to explain its role and advantages.

在考试环境中，你不会使用Git，但你应该能够解释其作用与优点。

---

11. Refactoring and Continuous Improvement | 重构与持续改进

Refactoring is the act of improving code structure without changing its external behaviour. It is a routine part of maintaining healthy code.

重构是在不改变外部行为的前提下改进代码结构的行为。它是在维护健康代码过程中的常规部分。

Common refactoring techniques:

常见重构技巧：

• Extract method — turn a long block into a named function.
• 提取方法 —— 将一个长代码块转换为具名函数。
• Rename variable — choose a clearer name based on today’s understanding.
• 重命名变量 —— 基于当前的理解选择更清晰的名称。
• Replace conditional with polymorphism — simplify branching in object-oriented code.
• 用多态替换条件语句 —— 简化面向对象代码中的分支。
• Remove dead code — delete unused functions and variables.
• 删除死代码 —— 移除未使用的函数和变量。

Rules of thumb: refactor in small steps and run tests after each step. Never refactor and add new features in the same change.

经验法则：小步重构，并在每一步之后运行测试。绝不在同一次变更中既重构又添加新功能。

---

12. Summary and Exam Points | 总结与考试要点

For CIE A-Level Computer Science, exam questions on maintainability may ask you to evaluate code, suggest improvements, or describe good practice. Use the following concise checklist in your answers:

对于CIE A-Level计算机科学，关于可维护性的考试题目可能会要求你评估代码、提出改进建议或描述良好实践。在答卷中使用以下简洁清单：

Aspect | 方面	Good Practice | 良好实践
Structure | 结构	Modular functions, each with one purpose | 模块化函数，每个函数单一用途
Naming | 命名	Meaningful, consistent names | 有意义且一致的名称
Comments | 注释	Explain why, not what | 解释为什么而非什么
Layout | 布局	Consistent indentation, short lines | 一致缩进，行文简洁
Duplication | 重复	DRY — extract repeated logic | DRY——提取重复逻辑
Constants | 常量	Replace magic numbers | 替换魔法数字
Errors | 错误	Validate input, use exceptions | 验证输入，使用异常
Testing | 测试	Automated unit tests, boundary cases | 自动化单元测试，边界情况

Remember: maintainability is not an afterthought — it is a continuous discipline that begins with your very first line of code. Marks are awarded for clear structure, suitable naming, relevant comments, and robust logic.

请记住：可维护性不是事后的补充——它是从你编写第一行代码就开始的持续性纪律。清晰的结构、恰当的命名、相关的注释和健壮的逻辑，这些都会为你赢得分数。

Published by TutorHao | A-Level Computer Science Revision Series | aleveler.com

更多咨询请联系16621398022（同微信）