1. 作业概览：这绝不是一次简单的“课后练习”
如果你只把这份“Python第二次作业”当成一次常规的语法巩固训练，那可能真的低估它了。我在实际批改和复现这类作业时发现，很多同学的卡点并不在“会不会写代码”，而在“能不能把学过的东西用对地方”。这次的作业看似是一个普通的课后练习，其实覆盖了Python入门阶段最容易被忽视的一批关键能力：数据类型的理解、面向对象的设计思路、文件读写的基本功、还有异常处理的实际运用。
先说结论：这份作业非常适合两类人参考——一类是刚学完Python基础语法、想检验自己掌握程度的新手，另一类是学完基础但不太清楚“这些知识点到底在真实项目中怎么串起来”的过渡期学习者。如果你正处于“能看懂别人的代码，但自己写就卡壳”的阶段，这次的作业就是一块很好的试金石。
作业本身并不复杂，它通常要求学生完成一个包含多个类、文件读写、以及数据统计的综合性小项目。绕开一堆形容词来说，它实质上把“用逻辑组织代码”这件事拆成了几个小关卡：先把数据正确地读进来，再通过类和对象组织业务逻辑，最后把结果以可读的形式写出去。任何一个环节掉链子，整个程序就会展现出各种“看起来莫名其妙”的问题。这也是为什么我每次复现这类作业，都会花不少时间在调试和排查上——很多报错信息根本不是代码写错，而是对数据流的理解出了问题。
我在下文会按照“拆解需求 → 设计结构 → 编码实现 → 排查问题”的思路，把这份作业从零开始讲透。你会看到我是如何思考的，哪些坑是我踩过后想提醒你注意的，以及每段代码背后的“为什么”。这不是一个标准答案的搬运，而是一次完整的、能让你真正上手的实操复盘。
2. 需求拆解与设计思路：作业背后的三座“暗礁”
2.1 表面上在考文件操作，实际上在考“数据流意识”
这类二次作业最常见的题目形式，是给你一个文本文件，里面存着若干条记录，比如学生成绩、商品库存、或者日志信息，要求你读取、解析、计算，再输出结果。很多人一上来就写个open()把文件读进来，再split()一下就算完事。可一旦数据量变大、格式出现异常、或者字段之间多了空格和空行，程序立刻就翻车。
我见过一个挺典型的场景：某同学写的程序在老师给的测试数据上跑得好好的，一换到真实场景的脏数据就报ValueError: not enough values to unpack。原因很简单——他在split()之后直接用了固定下标去取字段，而真实数据里有些行尾部多了换行符，有些行只有两个字段而不是三个。
如果你问我怎么看待这个问题：核心不在于那一行代码写错了，而在于“数据流意识”没建立起来。什么是数据流意识？就是你每读一行数据，心里要清楚这行数据现在是什么类型、是什么形态、里面有哪些字段、哪些字段可能为空、哪些字段可能是非法格式。带着这种意识去写代码，你会在解析之前先做清洗，在取值之前先做校验，而不是默认“测试数据永远干净”。
我在实际设计的时候，会把整个数据流分成四个阶段：读取阶段、清洗阶段、解析阶段、输出阶段。每个阶段干一件事，互不掺和。这样做的好处是：出问题的时候，你一眼就能看出问题出在哪个阶段，而不是在一个几百行的函数里挖地三尺。后面第4部分我会具体展开这个四阶段结构的代码怎么写。
2.2 表面上在考类与对象，实际上在考“设计的粒度”
第二个暗礁是面向对象。很多同学知道“类就是模板，对象就是实例”，但真到写代码的时候，要么把所有逻辑堆在一个类里写成一个巨型类，要么为了“面向对象”而强行拆分出毫无意义的类。
拿一个学生成绩管理的题目来举例。最简单的做法是写一个Student类，属性有姓名、学号、成绩，再写一个GradeManager类，负责管理所有学生的增删改查和统计。这个拆法的粒度是比较合理的：Student封装了单条数据的属性和行为，GradeManager封装了集合数据的操作和规则。但我在批改作业时经常看到另外一种写法——把Student类搞出七八个属性，连“是否及格”“成绩等级”这些本应由方法计算出来的东西也全部预先存进去，导致每次成绩一变，又得手动去同步等级字段，非常容易出现数据不一致的问题。
这里面有一个很核心的设计原则：能算出来的，就不应该存下来。成绩是否及格，应该由方法在运行时计算结果，而不是在对象创建时算一次然后存到一个布尔属性里。如果你遵守这个原则，程序会自然少掉一大类“状态不同步”的bug。我第一次意识到这件事，是在自己做一个库存管理系统的时候，当时把“是否缺货”放在了商品对象里，结果每天盘点时忘了更新这个字段，导致前端显示缺货的商品实际库存充足，后台显示正常的商品实际已经卖空了。
所以，在你写第二次作业的类设计时，我建议你先问自己几个问题：这个类的职责是否单一？每个属性是否都是必要的？哪些信息应该由方法计算而不是用属性存储？如果你能回答清楚这三点，你的类设计就算过关了。
2.3 表面上在考异常处理，实际上在考“防御式编程”
第三个暗礁藏在异常处理里。作业要求通常会包含“如果文件不存在，给出友好提示”或者“如果输入格式错误，程序不要崩溃”。大多数同学能做到最基础的try...except...，但这个水平距离真正的“防御式编程”还差了很远。
什么区别？举个最简单的例子。只捕捉异常的代码长这样：
try: with open("data.txt", "r", encoding="utf-8") as f: data = f.read() except Exception as e: print("出错啦")这段代码的问题在于：它把所有异常一锅端了。文件不存在、权限不足、编码错误、磁盘I/O错误，全部混在一起处理，用户只看到一句“出错啦”，完全不知道发生了什么。
我在自己的项目里更倾向于精确捕获异常类型，比如FileNotFoundError代表文件不存在，PermissionError代表权限不够，UnicodeDecodeError代表编码不匹配。同时，在上层调用者能感知到问题的地方，我会主动抛出带上下文的异常，而不是把错误信息吞掉。
如果你去翻优秀开源项目的源代码，你会发现它们对异常处理的重视程度远超你想象。一个健壮的程序不是“永远不会出错”，而是“出错的时候能告诉别人错在哪、怎么修”。这份作业正好给了你一个机会去练习这种思维。
2.4 设计总览：一张“输入 → 处理 → 输出”的隐形路线图
把所有需求合起来看，这份作业的完整路线图其实是这样的：
输入层是一个文本文件或用户交互输入，处理层由若干类和方法组成，负责解析数据、组织逻辑、执行运算，输出层把处理结果写回文件或打印到控制台。三者之间通过清晰的数据结构传递信息。
这看起来像是教科书里的分层架构，但对一个小作业来说，它的意义在于帮你养成一种“模块化思考”的习惯。就算你不写类，全部用函数实现，也完全可以。函数式的方案没什么不行，关键是让读代码的人一眼能看出“这段是读数据”“这段是清洗”“这段是计算”。
我个人更推荐用面向对象的方式写，不是因为“工作中都用OOP”，而是因为第二步作业的题目天然适合类和对象来建模——你要处理的对象就是学生、商品、日志这些实体，你直接为它们建模是最自然不过的事。
3. 核心细节解析：从零写起，每一行都说得清为什么
3.1 环境的准备：比你想的更关键
开始写代码前，先确认环境。我经常见到同学在本地跑得好好的代码，换一台机器就报ModuleNotFoundError，原因就是用了没安装的第三方库。这次作业如果只是一个纯标准库的项目，就不会有这个问题，但很多同学的题目引入了外部文件或者CSV数据，我就建议先确认真实的运行环境。
有一个最容易被忽略的细节：文件的编码格式。Windows系统上新建的文本文件，默认可能是GBK编码，而Python默认打开文件用的是系统编码，如果你用encoding="utf-8"去读一个GBK文件，会出现乱码或者直接报错。我处理这类问题的办法是养成了一个习惯——读写文件时总是显式指定编码：读的时候写encoding="utf-8"，但一旦遇到乱码问题，先检查一下文件本身的编码是什么，而不是盲目猜测。
另一个细节是文件的路径。很多同学把数据文件和脚本放在同一个目录下，就直接写open("data.txt")，这在脚本从命令行运行时没问题，但如果脚本是从别的目录被调用的，相对路径就失效了。保险的做法是先用pathlib.Path(__file__).parent拿到脚本所在目录，再拼上数据文件的名字。我一直认为pathlib是Python一个被低估的宝藏模块，尤其在处理路径拼接时，比手写字符串加/要安全得多。
3.2 类的设计：属性要少，方法要专
接下来进入核心设计环节。我设计Student类的时候，只让它拥有三个属性：姓名、学号、成绩。一个学生的其他详细信息，比如年龄、班级、联系方式，在这个作业的语境里统统不需要。这不是偷懒，是“够用就好”。属性太多，一是初始化时容易漏传，二是万一将来要修改需求，你得花更多时间维护。
Student类的方法我一般只放两个：一个is_pass()判断是否及格（成绩大于等于60），一个get_level()返回成绩等级（优秀、良好、及格、不及格）。你可能问：就这么点逻辑，还需要封装成方法吗？答案是需要的。因为如果统计模块里到处写着if score >= 60，一旦及格线从60改成70，你就得改七八处地方；可如果你调用的是is_pass()，只需要改这一个方法。这就是“封装”带来的最直接好处。
再设计GradeManager类，它负责维护一个学生列表。类中至少要有这些方法：add_student()添加学生，remove_student()按学号删除学生，find_student()按学号查找学生，get_average()计算平均分，get_rank()进行排名，load_from_file()从文件读入数据，save_to_file()将数据写回文件。
这个类的思路很清晰：它是所有学生对象的“集合管理者”，外界的代码不直接操作列表里每一项，而是通过GradeManager提供的方法间接操作。这样就让代码有了一个明显的“门面”——你不需要关心内部数据是存在列表里还是字典里，你只需要调用统一的方法。这个设计思想，在工作中做稍微复杂一点的系统时，可以说是必然的选择。
我还想提一个细节：成绩数据用列表存还是用字典存？我的建议是，如果学生数量不大并且没有大量随机查找的需求，列表就够了；如果你需要频繁按学号查找，那用字典把学号映射到学生对象会更高效。你可以把这个选择当作一个思考题，而不是死记硬背的结论。这样设计的时候你就理解了：数据结构的选择取决于使用场景。
3.3 读入与写出：四阶段数据流的具体落地
第2部分提到的四阶段数据流，这里给出具体实现。
读取阶段只负责把文件内容读出来，不做任何解析：
from pathlib import Path base_dir = Path(__file__).parent file_path = base_dir / "students_data.txt" def read_raw_data(file_path: Path) -> str: try: return file_path.read_text(encoding="utf-8") except FileNotFoundError: raise FileNotFoundError(f"数据文件不存在: {file_path}")注意两个细节：一是用Path.read_text()替代open()加.read()，代码更简洁；二是异常抛出去之后，由上层调用者决定怎么处理，而不是在读取函数里自己print()完就完了。
清洗阶段负责把原始文本变成“干净的行列表”。实际文件里的问题远比想象的多：空行、首尾空格、多余的空白字符、全角标点等。我一般这样处理：
def clean_lines(raw_text: str) -> list[str]: lines = [] for line in raw_text.splitlines(): line = line.strip() if line: lines.append(line) return linessplitlines()是按行拆分，strip()去掉两端的空白，空行直接丢弃。这一步看似简单，但它帮你免去了后续大量“多了一个空格导致解析失败”的烦恼。
解析阶段是把干净的行转换成结构化数据。假设每行的格式是“姓名,学号,成绩”：
def parse_line(line: str) -> Student: parts = [part.strip() for part in line.split(",")] if len(parts) != 3: raise ValueError(f"数据格式不正确: {line}") name, student_id, score_str = parts try: score = float(score_str) except ValueError: raise ValueError(f"成绩不是数字: {score_str}") return Student(name=name, student_id=student_id, score=score)这一阶段我最看重的是对格式的校验。我曾经遇到过一份数据，其中一行是“张三,001,八十五”，成绩列居然是个中文汉字。如果不做类型校验，float("八十五")会直接抛异常；做了校验之后，程序可以明确指出“成绩不是数字: 八十五”，这就能让使用者直接定位到脏数据。
输出阶段把计算好的结果写回文件。这里我特别想说一点：不要用"a"追加模式写结果，除非你明确知道自己在做什么。我见过有同学每次运行程序都用追加模式，结果跑十次程序，输出文件里出现了十份重复的统计结果。一般我用"w"模式，覆盖写入，每次运行生成一份干净的结果文件。
3.4 统计逻辑：少写魔法数字，多写有名字的常量
统计平均分、最高分、最低分，这类逻辑本身不难，难点在于代码的可读性。比如你写if score >= 60，读者心里要猜“60是什么？”如果改为：
PASS_SCORE = 60 EXCELLENT_SCORE = 90 def is_pass(self) -> bool: return self.score >= PASS_SCORE这样任何人读代码时都不需要猜了。我把这种做法称作“给魔法数字起名字”。在作业规模不大时它显得有点多此一举，但一旦你参与真实项目开发，这种习惯的好处会越来越明显——数字从哪来、为什么定这个值、以后会不会变，这些问题都有迹可循。
还有一个小技巧：计算汇总统计时，如果数据量不大，直接遍历列表即可，不需要引入复杂算法。但如果你想更优雅一点，可以试试内置的sum()、min()、max()配合生成器表达式：
scores = [student.score for student in self.students] average_score = sum(scores) / len(scores) max_score = max(scores) min_score = min(scores)这里一定要先判空，否则sum([])会得到0，max([])会直接抛ValueError。我在第4部分会专门讲这个坑。
3.5 异常处理：给用户看提示，给开发者看细节
如果你只在作业里写“file not found”的提示，基本够了。但我更建议你做一个“双层提示”：给普通用户看一句话“数据文件不存在，请检查文件是否放在了脚本目录”，同时在日志或者注释里保留完整的异常信息。
实践中我喜欢用logging模块记日志，而不是直接用print()。打印和日志的区别在于：日志可以分级、可以输出到文件、可以保留堆栈信息。对这个作业来说，用logging.exception()把出错时的上下文记录到日志文件，你在调试时会省去大量的“这个错误到底是哪行代码触发的”的猜测。如果作业没有特殊要求，用一个简单的logging.basicConfig(level=logging.INFO)就够了。
4. 完整实操流程：一边写一边跑，看它如何从0到可用
4.1 定义数据文件的结构
为了让这一整套流程有血有肉，我构造了一份模拟的学生成绩数据文件students_data.txt，每行是一条记录，用英文逗号分隔三个字段：姓名、学号、成绩。
张三,001,87 李四,002,52 王五,003,93 赵六,004,61 钱七,005,76 孙八,006,88 周九,007,64 吴十,008,99这份数据故意设置了一些“可挖掘”的点：平均分分布在多个等级区间，有不及格案例（李四的52分），有高分案例（吴十的99分）。这样你跑完统计之后，各个统计指标都有原型数据可以做验证。
4.2 编写第一个可用版本
我建议不要一上来就写全部代码。先写一个最简版本，只完成“读取文件 → 输出平均分”的闭环，确认环境没问题、数据能读进来、编码没乱，再逐步增加功能。这个过程我称之为“先打通一条线，再填充扩展”。
第一个完整可用版本大致如下：
from pathlib import Path PASS_SCORE = 60 class Student: def __init__(self, name: str, student_id: str, score: float): self.name = name self.student_id = student_id self.score = score def is_pass(self) -> bool: return self.score >= PASS_SCORE def get_level(self) -> str: if self.score >= 90: return "优秀" elif self.score >= 80: return "良好" elif self.score >= 60: return "及格" else: return "不及格" class GradeManager: def __init__(self): self.students = [] def load_from_file(self, path: Path) -> None: raw_text = path.read_text(encoding="utf-8") self.students = [] for line in raw_text.splitlines(): line = line.strip() if not line: continue parts = [part.strip() for part in line.split(",")] if len(parts) != 3: raise ValueError(f"数据格式不正确: {line}") name, student_id, score_str = parts try: score = float(score_str) except ValueError: raise ValueError(f"成绩不是数字: {score_str}") self.students.append(Student(name, student_id, score)) def get_average(self) -> float: if not self.students: raise ValueError("学生列表为空，无法计算平均分") return sum(s.score for s in self.students) / len(self.students) def get_pass_rate(self) -> float: if not self.students: raise ValueError("学生列表为空，无法计算及格率") pass_count = sum(1 for s in self.students if s.is_pass()) return pass_count / len(self.students) def save_summary(self, path: Path) -> None: avg = self.get_average() rate = self.get_pass_rate() lines = [ f"学生人数: {len(self.students)}", f"平均成绩: {avg:.2f}", f"及格率: {rate:.2%}", ] path.write_text("\n".join(lines), encoding="utf-8")这版代码虽然简单，但已经体现出了前面讨论的几个要点：常量起名字、类职责分离、异常抛给上层。跑一下，再把输出文件打开看一眼，你会发现{rate:.2%}这个格式化语法会把0.75自动显示成“75.00%”，这就是Python格式化输出的便利之处。
4.3 增加排名与学生明细导出
光有统计汇总还不够，作业通常还要求输出每个学生的成绩等级和排名。我增加一个方法：
def get_sorted_students(self) -> list[Student]: return sorted(self.students, key=lambda s: s.score, reverse=True) def save_student_details(self, path: Path) -> None: sorted_students = self.get_sorted_students() lines = ["姓名,学号,成绩,等级,排名"] for index, student in enumerate(sorted_students, start=1): lines.append( f"{student.name},{student.student_id},{student.score},{student.get_level()},{index}" ) path.write_text("\n".join(lines), encoding="utf-8")然后写一个简单的main()函数把它们串起来：
def main(): base_dir = Path(__file__).parent data_file = base_dir / "students_data.txt" summary_file = base_dir / "summary.txt" detail_file = base_dir / "student_details.csv" manager = GradeManager() manager.load_from_file(data_file) manager.save_summary(summary_file) manager.save_student_details(detail_file) if __name__ == "__main__": main()运行后检查两个输出文件，如果内容都正确，说明这个作业的核心链路已经通了。整段代码不足百行，但已经把面向对象、文件操作、异常处理、格式化输出全部串了起来。
4.4 加上命令行交互
作业偶尔还要求支持用户自行输入，比如输入姓名查询成绩。我用一个循环做交互，这段代码虽然简单，却是很多同学容易忽略“防御性”的地方——用户输入学号时可能带了空格、输错大小写、甚至输入了不存在的人名。所以我加了.strip()清洗输入、添加“未找到”的友好提示：
def query_student(manager: GradeManager) -> None: while True: student_id = input("请输入学号查询成绩（输入q退出）: ").strip() if student_id.lower() == "q": break found = manager.get_student_by_id(student_id) if found: print(f"{found.name} 的成绩是 {found.score:.2f}，等级为 {found.get_level()}") else: print("未找到该学号，请确认后重试")get_student_by_id在GradeManager中实现：
def get_student_by_id(self, student_id: str) -> Student | None: for student in self.students: if student.student_id == student_id: return student return None这里用了| None做类型注解，表示方法可能返回“没有找到”的空值。在使用方先判断是否为空，再做后续处理，这个模式我在项目里反复用，算是处理“查询不到数据”最直接的方式。
5. 常见问题排查与避坑指南：我把踩过的坑都排了一遍
5.1 文件编码问题：打开就乱码，或者直接报错
这是出现频率最高的一个问题。症状是：在某个同学的电脑上程序跑得好好的，代码传到你电脑上运行，中文全部变成乱码，或者直接抛UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb4 in position 0。
我处理这个问题的顺序是先看报错信息，再检查源文件编码。如果是UnicodeDecodeError，说明你用utf-8去读了一个非UTF-8编码的文件；如果是乱码，大概率是源文件是UTF-8，你读的时候用了系统默认的GBK。解决办法是：在读取时显式指定与文件实际编码一致的编码。如果你不知道文件的编码格式，用文本编辑器打开文件后另存为时能看到当前编码，或者在命令行里用file命令检测。
还有一个防坑建议：在项目中写一个统一读取文件的小函数，把所有编码处理集中在一个地方。这样如果将来换文件格式，只改一个函数就行，而不是满项目地找open()。
5.2 空文件导致的计算错误
当你对一个空列表调用max()或计算平均值时，程序会怎样？sum([]) / 0会抛ZeroDivisionError，max([])会抛ValueError: max() arg is an empty sequence。这些异常不算难处理，难的是你压根没想到数据文件会是空的。
我遇到过一次极端情况：数据文件只有标题行，没有数据行。加载函数成功执行了，但统计模块一跑，程序就崩了。从那以后，我在所有涉及集合运算的逻辑里都加上了判空操作，而且是在计算之前就判，不是等异常冒出来再处理。这不是小题大做，而是“预期管理”——你应该默认用户输入和外部数据都是不可靠的，凡是需要先有数据才能做的操作，都要先确认“有数据”这个前提成立。
5.3 数据的“尾巴”问题：换行符和不可见字符
我早年在处理从Windows复制过来的文本文件时，遇到过\r\n换行符的问题。在Windows系统创建的文本中，换行由\r\n两个字符组成，而Linux和macOS使用\n。Python的splitlines()能够自动处理两种换行，但如果你用line.split(",")去拆分字段，最后一个字段后面可能还带着一个\r，导致学号从"005"变成"005\r"。
我的应对策略是：只要是从文本文件读取的字符串，一律先.strip()再使用。如果你已经遇到了这种问题，可以在可疑字段上打印repr()看看实际的字符是什么，这是定位不可见字符最有效的办法，没有之一。
5.4 成绩小数与精度问题
如果你在成绩中用了浮点数，比如87.5分，那么在比较和格式化时会出现一些微妙的问题。87.5的float表示其实是87.50000000000001左右（取决于具体的二进制表示），虽然打印出来看着是87.5，但在做精确比较、甚至相加时，可能会有一点点误差。
对于成绩这种精确到小数点后一到两位的场景，我建议用float但在计算时用round()做处理，或者如果成绩全是整数，直接用int更干净。关于“用Decimal还是float”，一般作业场景不需要上升到这个复杂度，但你要知道有这回事。
5.5 输出文件内容覆盖还是追加？别再来一份重复汇总
我在第3.3部分提过追加模式带来的麻烦，这里用真实的案例再说一次。某位同学为了保存多次运行的结果，在save_summary里用了"a"模式，结果跑了三次之后，输出文件里出现了三份汇总数据，而且中间没有分隔，看起来就是一团乱。后来的统计脚本直接把这个文件当成输入数据去解析，结果自然是格式错误。
如果你确实需要保留历史记录，可以用"a"模式，但应该在写每份汇总之前加一行时间戳或者分隔线，让文件可读。如果不是特殊需求，就用"w"模式，覆盖写入，每次运行得到一份干净的结果。我在项目里养成的习惯是：汇总类输出用"w"，日志类输出用"a"。两者用途不一样，将来你看到这个约定时不需要犹豫。
5.6 路径问题：脚本不在当前目录时，相对路径失效
你在IDE里按“运行按钮”时，程序的工作目录通常是项目根目录。但当你在命令行手动执行python /path/to/script.py时，当前目录就是命令行所在的位置，不再是你代码所在的目录。此时如果用相对路径"data.txt"，程序就会打开一个不存在的路径。
我曾经有一次在某个自动化任务里直接跑了脚本，一直报“文件不存在”，却怎么也想不通，最后才发现脚本是从另一个目录被调用的。从那以后，我写代码默认用Path(__file__).parent来定位脚本所在目录，再基于这个目录去拼接其他文件的路径。这个方法既简单又可靠，几乎适配所有的项目场景。
5.7 交互输入的死循环问题
如果交互循环写得不严谨，用户输错一个学号之后，程序可能陷入“未找到学号”的无限循环里出不来。我见过一个版本：用户输入了不存在的数据，但因为代码里缺了“退出条件”的判断，输入5次之后用户只好直接关闭终端。
这个问题的根因是：设计交互时没有想清楚“终态是什么”。我的建议是，每次交互起码提供两种退出方式：一是输入特定的关键词（如q）退出，二是收到Ctrl+C中断信号时，用try...except KeyboardInterrupt捕获并给出退出提示。这样用户在正常和异常两种情况下都能体面地终止程序。
5.8 小项目必然遇到的“重构需求”
最后一个不算bug但很常见的困惑是：明明作业已经做完了，老师又说要增加一个功能，比如增加“按班级分组统计”。如果你前期把类的职责拆得清晰，这个功能只是增加一个新方法而已；如果你把所有逻辑都堆在main()里，这一个新的功能可能要你把整段代码推倒重来。
我自己带过的项目团队里，很多人早期写代码没有“为扩展留余地”的意识，后来每次加需求都像在玩“叠叠乐”，加到第10次的时候，代码已经开始摇摇欲坠。你在第二次作业里，耐心一点把类和方法拆好，后面改需求时就体会得最明显。
6. 经验总结：做这个作业时，我最终学会的三件事
说实话，以我现在的眼光回看这类第二次作业，它真的不复杂——几十行代码，几个类，两个文件读写就能撑起来。但我在辅导别人改这段代码的过程中，反而收获了不少东西，这里分享三条比较有价值的体会，也算是对这篇博文的一个收尾。
第一，代码写得好不好，不看技巧看结构。很多人比拼谁用了更花哨的列表推导式、更复杂的装饰器，我觉得这从一开始就偏了。这份作业你给我用两百行写出来和老老实实六七十行写出来，只要结构清晰、职责明确、好改好读，我反而会给后者更高的评价。把复杂的东西拆简单，是一种更难得的能力。
第二，异常处理的本质不是“防止崩溃”，而是“清楚地向他人传达发生了什么”。每一次except都是一个与未来的自己或他人的对话机会。你在这个过程中给出了多少信息，别人调试起来就有多顺。这个道理我在做一些内部工具、共享给别人使用时体会得格外深——对方不会读你的代码，他们只会看到那句“文件不存在，请检查路径”，这句提示能不能让他们马上反应过来去做什么，就决定了工具的可用程度。
第三，也是最重要的一条：别怕把数据打印出来。我见过太多同学源代码写完了，却因为数据文件的格式和想象的不一样而在解析阶段卡很久。你一边写代码一边打印出中间结果，是在供电，不是在求人。把读取到的repr看一遍，把解析后的对象属性打印一遍，把输出文件用文本编辑器打开看一眼，这三个动作做完，80%的问题在你自己手里就已经消失了，根本不需要到处问人。
如果你正在写这份作业，我真心建议你按四阶段数据流的方式把代码组织一下，不需要追求什么高深莫测的设计，只要能清楚回答“数据从哪来、到哪去、中间经历了什么变化”这三个问题，你的代码就已经超过了大多数同期学习者。做完之后，把代码留好，过三个月回头再看一次，你会看到自己的进步有多大。
