[l.1] 个人作业：阅读与提问

个人作业：阅读和提问

项目	内容
这个作业属于哪个课程	https://edu.cnblogs.com/campus/buaa/BUAA_SE_2026_LR
这个作业的要求在哪里	https://edu.cnblogs.com/campus/buaa/BUAA_SE_2026_LR/homework/15608
我在这个课程的目标是	了解软件工程课程，学会科学地提问
这个作业在哪个具体方面帮助我实现目标	通过阅读邹欣的《构建之法：现代软件工程》 。还没有课本，主要是链接的博客

问题1

• 阅读内容：在个人开发技术的PSP相关内容中，作者认为工程师记录每项活动的时间，精确到分钟，以此来度量个人的生产率。
• 我的问题：在实际开发中，频繁切换上下文和被打断是常态，这种精确记录是否真的具备可操作性？
• 其他说法：作者提到要通过纪律和工具来辅助记录，长期坚持能提高预估准确性
• 我的经验：基于大三上学期编写课设编译器的经验而言，很多时候会被其他一些事情所干扰，比如其他课程或者学业规划。很难严格区分"设计"、"编码"和"调试"的时间边界，很多时候它们是交织在一起的。
• 我的困惑：这种高度理想化的时间度量，对于像我现在这样时间碎片化、有其他压力的个人开发者来说，除了增加记录负担，真的能显著提升效率吗？

问题2

• 阅读内容： 在单元测试相关章节中，作者强调代码要有单元测试，且要追求较高的覆盖率，甚至提到TDD（测试驱动开发）是现代软件工程的核心实践。
• 我的问题： 对于逻辑高度耦合、内部状态复杂的底层系统软件，单元测试的边界在哪里？
• 其他说法： 流行的说法是"单元测试能保证代码质量，方便重构，是现代软件工程的基石"。
• 我的经验： 我自己写编译器时，源语言是C的子集，虽然没有指针，但在做语义分析和中间代码生成时，很多状态是链式传递的。单独mock（模拟）数据去测试某个语法解析函数极其困难，往往写测试的时间比写功能的时间还长。
• 我的困惑： 在一个人独立开发且逻辑高度耦合的底层项目中，强行推行单元测试，会不会反而因为维护测试用例的成本而拖慢了整体进度？

问题3

• 阅读内容： 在敏捷开发章节中，作者介绍了敏捷流程，强调快速迭代、每日站会、结对编程等，认为这能显著提高团队效率。
• 我的问题： 这种看似高效的流程，在没有外部商业利益驱动的学生团队中，是否会流于形式？
• 其他说法： 敏捷宣言强调"响应变化胜于遵循计划"，业界普遍认为敏捷能保持团队专注。
• 我的经验： 大二大三参与某些课程的团队项目时，所谓的"敏捷"往往变成了频繁的扯皮和无效会议。因为大家并没有真正的利益捆绑，责任心也参差不齐，反而不如一个人安安静静写代码效率高。
• 我的困惑： 在缺乏职业化管理约束的学生团队中，敏捷流程是解药还是毒药？是否反而增加了沟通成本？

问题4

• 阅读内容： 在代码规范相关章节，作者强调代码风格要统一，可读性是第一位的，反对过于晦涩的写法。
• 我的问题： 当"优雅的规范"与"底层硬核实现"发生冲突时，该如何取舍？
• 其他说法： 教材认为好的代码应该像散文一样易读，不应包含过多的"魔术数"和复杂逻辑。
• 我的经验： 在学习《计算机组成原理》和《操作系统》时，我发现很多底层代码（如内存管理、寄存器调度）为了极致的性能和硬件交互，往往充满了位操作、硬编码和紧凑的逻辑，这与面向对象编程追求的"封装"和"清晰"背道而驰。
• 我的困惑： 对于系统级软件开发，过分强调教科书式的代码规范，是否会导致性能上的妥协？规范在什么程度下必须向底层现实低头？或者如果可能的话，能否给出比较清晰的边界？

问题5

• 阅读内容： 在软件设计与架构部分，作者提到了面向对象的设计原则（如单一职责原则、开闭原则等），鼓励设计灵活、可扩展的架构。
• 我的问题： 在需求极其明确且资源受限的场景下，过度遵循设计原则是否属于"过度设计"？
• 其他说法： 设计模式书籍通常建议"针对接口编程，不针对实现编程"，以应对未来的变化。
• 我的经验： 我在编写编译器时，因为源语言定义已经固定（只包含整数和一维数组），需求几乎不会变更。如果为了"可扩展性"强行套用各种设计模式，反而会增加大量冗余的类和虚函数调用，降低编译速度。
• 我的困惑： 如果需求已经像编译器规格说明书那样白纸黑字确定下来，我们是否还需要为了"应对未来的变化"而牺牲当下的简洁与效率？

问题6

• 阅读内容： 在团队协作章节，作者提倡"每人负责一个模块"，明确责任边界，以此提高团队协作效率。
• 我的问题： 在涉及全栈理解的项目中，这种切分是否会造成知识的孤岛？
• 其他说法： 管理学理论认为明确的责任划分能避免推诿扯皮，提高专业度。
• 我的经验： 在《操作系统》课程实验中，如果我只负责内存管理模块，而完全不懂文件系统模块，一旦两个模块交互出现Bug，双方都很难定位问题，因为缺乏全局视角。我写编译器时，正是因为从头写到尾，才能快速定位是词法分析的问题还是代码生成的问题。
• 我的困惑： 这种"切豆腐块"式的分工，是否会让工程师变成只会拧螺丝的流水线工人，从而丧失对系统整体架构的把控能力？

问题7

• 阅读内容： 在工程师的成长章节，作者提到了用Bug率、代码行数等指标来度量和评价工程师的表现。
• 我的问题： Bug的数量和质量是否应该被同等看待？低Bug率一定代表高水平吗？
• 其他说法： 软件工程强调质量，Bug越少越好，修复Bug的时间越短越好。
• 我的经验： 在《面向对象编程》课程中，有时为了赶进度写出的代码虽然Bug多，但逻辑复杂且实现了核心功能；而有时写得简单Bug少，是因为规避了难点。此外，我在编译器实现中发现，有些逻辑Bug可能只需改一行代码，但有些设计缺陷需要重构整个模块。在《编译技术》课程实验中，我也为了避免bug来采取保守的优化策略，这也导致了性能不如别人。
• 我的困惑： 单纯用Bug率来考核，会不会导致开发者为了指标而故意写简单保守的代码，反而不敢挑战高难度的技术实现？