第一周作业

这个作业属于哪个课程 软件工程 - 广东工业大学计算机科学与技术
这个作业要求在哪里 第一周作业要求
这个作业的目标 熟悉博客园 Markdown 排版规范；完成个人学习现状复盘；制定课程、能力与未来发展规划；学会规范提问、明确学术底线与规范引用；研读前辈经验反思自我；搭建 GitHub 个人仓库，建立长期技术复盘的写作习惯。

软件工程第一次作业随笔

一、个人介绍与建博客初衷

1. 个人基本情况

我是广东工业大学计算机学院计算机科学与技术专业的一名在读本科生。在性格上，我属于偏向稳重、喜好安静思考与深度沉淀的类型。面对繁杂多变的信息，我更习惯静下心来理清底层脉络，而不是随波逐流。

在课余时间，我长期保持着一项需要高度耐心与专注的爱好，拼乐高积木。长期的拼装不仅让我体会到了从生疏到熟练的渐进过程，更在潜移默化中培养了我极强的自律意识、细节把控力与耐受枯燥的能力。在计算机专业的学习中，反复调试难以复现的 Bug、逐行研读复杂的开源项目源码、耐心推导算法逻辑，本质上都极为消耗心力。正是这些看似与编程无关的爱好习惯，构成了我能够在电脑前潜心钻研数小时、不浮躁、不放弃的心态基石。

2. 建博客初衷

本次开通博客园并开启课程随笔，绝不仅仅是为了应付一门课的学分考勤，而是为了给自己的大学后半段建立一个公开、系统且持续的知识沉淀载体。

在阅读了刘未鹏老师的《为什么你应该（从现在开始就）写博客》后，我受到了极大的触动。刘老师在文中指出：“教是最好的学，写博客是倒逼自己理清思维的最优途径。”很多时候，我们以为自己“听懂了”或者“代码跑通了”，其实大脑中充斥着大量的思维断层与模糊假设。只有当我们尝试把一个技术问题、一次 Bug 排查、一次架构设计用规范、清晰的文字讲给别人听时，那些潜藏在暗处的知识盲区才会彻底暴露出来。写博客能够：

  • 穿透知识假象：把零散、碎片化的代码直觉转化为逻辑严密的技术表达；
  • 沉淀长尾价值：建立属于自己的“外部大脑”与知识检索库，解决过的问题不再重复踩坑；
  • 积累信任资产：将平时的代码轨迹、复盘思考转化为看得见的专业声誉，为未来的考研复试或求职面试提供最有说服力的能力证明。

3. 个人闪光点

如果跳出单一的应试成绩评价体系，我认为我最大的闪光点在于：具备高度的自律性、敏锐的问题嗅觉，以及长期主义的抗挫力。在遇到陌生的技术栈或棘手的工程难题时，我不会轻易陷入焦虑，而是擅长将大问题逐层拆解为最小可验证的单元，逐步攻坚；同时，我有良好的复盘习惯，善于在每次失败中提炼经验教训，将“踩坑”转化为自身能力的增长点。

4. 学术诚信与作业底线

技术可以循序渐进，但诚信底线不可逾越。在开课伊始，我认真研读了邹欣老师的《作业的底线》。我在此郑重承诺：在软件工程课程的所有作业、博客写作、实验编码以及团队项目中，坚决坚守学术诚信底线，坚持独立思考，坚决杜绝任何形式的抄袭剽窃、代码克隆与洗稿伪装。

二、学习现状、经验复盘与本学期详细规划

（1）专业选择、能力差距与技能提升计划表

我选择计算机科学与技术专业，是因为被“通过代码构建系统、自动化解决真实世界问题”的创造力所吸引。经过前两年的基础学科训练，我逐渐认识到，掌握语法和算法题并不等同于具备真正的软件工程能力。对照合格的 IT 专业毕业生与工业界研发要求，我在真实系统设计、代码健壮性、自动化测试、工程化协作等方面依然存在显著差距。

参考邹欣老师在《现代软件工程讲义 个人能力的衡量与发展》中提出的学长能力衡量标准（采用 0~9 分制：0 分代表完全不了解，5 分代表达到企业面试与合格工程师门槛，9 分代表国际顶尖水准），我选取了软件开发全生命周期中的 7 项关键工程能力进行客观自评，并制定了本学期的具体提升路径：

核心技能项 目前水平 (0-9) 课程结束目标 (0-9) 具体提升手段（至少 5 条落地举措）
1. 需求分析与方案设计能力 3 6 1. 严格按照用户故事（User Story）与规范用例图梳理功能边界，杜绝凭空臆想需求；
2. 学习使用 Markdown / Mermaid / PlantUML 绘制规范的时序图、类图与状态流转图；
3. 在个人和结对项目中落实原型设计（如 Figma/墨刀），先定接口与交互，再写业务代码；
4. 团队项目期间主动参与需求评审，对不合理、模糊的需求提出质疑并输出分析文档；
5. 参照经典开源项目的架构设计文档，分析其模块解耦与职责划分的合理性。
2. 代码规范与工程健康度 4 7 1. 严格配置并使用 Linter 工具（如 ESLint / Pylint / clang-format），将代码风格告警全部消除后再提交；
2. 实行防御式编程，在关键函数入口统一进行边界检验与异常断言，拒绝裸跑；
3. 坚决消除函数超长、圈复杂度过高以及死代码，每次完成功能后强制进行重构优化；
4. 规范 Git Commit Message（采用 Angular 规范：feat/fix/docs/refactor），保证每次提交原子化且语义清晰；
5. 坚持代码注释与接口文档同步更新，拒绝写充满临时废弃代码的“一次性玩具”。
3. 自动化测试与质量保障能力 2 6 1. 系统掌握单元测试框架（如 pytest / JUnit / GoogleTest），坚持为核心业务模块补齐测试用例；
2. 核心算法与业务逻辑单元测试代码行覆盖率力争达到 70% 以上；
3. 重点设计边界用例、空值用例、大并发/超长输入等异常流测试，先想“怎么把程序测崩”再写实现；
4. 学习使用 Mock 技术隔离数据库、网络请求等外部环境依赖，确保测试快速且确定性运行；
5. 搭建 GitHub Actions 持续集成工作流（CI），实现每次 Push / PR 自动执行全量测试套件。
4. 系统调试与根因排查能力 4 7 1. 摒弃单一的 print 调试法，熟练运用断点调试器（GDB / VS Code Debugger），掌握条件断点、调用栈回溯与内存观察点；
2. 养成遇到报错先仔细阅读完整 Traceback / Error Log 的习惯，精准定位报错首发位置；
3. 建立个人专属的“Bug 排查与填坑笔记”，对空指针、内存泄漏、并发竞争等典型 Bug 分类归档；
4. 掌握基础性能剖析（Profiling）工具，能够排查 CPU 占用过高与内存瓶颈；
5. 在结对编程中刻意练习“橡皮鸭调试法”，向同伴准确口述数据流向与异常分支。
5. 代码阅读与开源工程复现能力 3 6 1. 本学期精读至少 1~2 个成熟开源项目的核心模块源码，绘制模块调用拓扑图；
2. 学习快速通读官方英文文档与 RFC 规范，减少对二手水文博客的依赖；
3. 练习从零搭建他人项目的构建环境，遇到依赖报错时自行排查 CMake / Makefile / package.json 配置；
4. 坚持写源码阅读分析随笔，记录优秀的架构设计模式（如工厂、单例、观察者、策略模式）；
5. 尝试在 GitHub 上为开源项目提交 Issue 或修补简单的文档/拼写错误 PR。
6. 团队协作与版本控制能力 3 6 1. 熟练掌握 Git 进阶操作：分支管理（Git Flow）、冲突解决、rebase、cherry-pick；
2. 在结对和团队项目中严格执行 Pull Request 与 Code Review 制度，每次合并前必须经过同伴审查；
3. 严格遵循团队统一的代码规范与接口协议，杜绝单打独斗和个人代码风格污染公共仓库；
4. 学习使用 GitHub Projects / 敏捷看板管理任务状态，每天在站会中明确对齐“昨日进展-今日计划-阻碍卡点”；
5. 尊重团队分工，具备技术妥协意识与沟通同理心，以项目整体稳定交付为最高目标。
7. 技术写作与复盘自省能力 4 7 1. 严格遵守 Markdown 与中文文案排版规范（中英文空格、标点符号规范、层级标题分明）；
2. 每次作业与项目结束后，当天完成复盘随笔，记录“设计初衷-遇到阻碍-解决思路-经验总结”；
3. 在博客中提供完整的复现步骤、测试数据和可运行示例，拒绝空洞概念堆砌；
4. 主动阅读优秀同学与助教的博客，在互评交流中吸取长处并持续优化自身表达；
5. 坚持写结构化、模块化的技术文档，将每次开发沉淀为可复用的知识模块。

（2）课程阅读心得与学习态度

① 专注力学习心得

阅读了 Scalers 的《别让你的注意力被收割》以及 CookieLau 的博客园解读《停下来，回头看》，我获益匪浅：

  • Scalers 强调，聚精会神在信息碎片化的时代已经成为极度稀缺的核心竞争力。大学课堂不仅是传授具体公式的场所，更是锤炼深度注意力的训练场。如果学生总是以“老师讲得无趣”、“这门课没用”为由走神刷手机，实质上是在纵容自己心智的散漫，终将被算法与短平快的信息收割。
  • 而 CookieLau 则从学生的一线体验出发，提出了极具现实意义的辩证视角：现实中的课堂质量确实参差不齐，机械式念 PPT 的课堂很难激发内在动力。但更关键的一点在于：“不跟着照本宣科的讲稿走”绝对不等于“彻底放弃学习而刷手机”。在不够理想的课堂环境中，能够抵抗外界干扰、独善其身、在台下安静地自主研读优质材料，同样是一种难能可贵的聚精会神。

我的反思与态度：
我深切认同“专注力如同肌肉，需要刻意锻炼”。面对软件工程这样高强度的实践课，无论是需求推导、架构设计还是多线程排错，都需要连续数小时的高密度专注。未来在课堂与自习中，我将坚决杜绝“上课玩手机、DDL 前突击抄代码”的浮躁作风。当老师讲授启发性内容时，紧跟思路积极互动；当遇到照本宣科的内容时，自主研读教材与官方文档，绝不把“课水”当作自己放任自流、注意力涣散的借口。

② 师生关系与作业态度

在研读了邹欣老师的《现代软件工程讲义 0 教学方法》后，我对大学师生关系有了全新的认知：
邹欣老师剖析了大学中常见的种种畸形关系——“蜡烛-树苗”（过度道德绑架）、“餐馆-食客”（交钱买学分、偏爱低作业高给分的水课）、“老板-雇员”（沦为廉价劳动力）、“保姆-幼儿”（投喂式教学催生巨婴）、“哥们-哥们”（心照不宣一起混）、“狱警-犯人”（点名应付与防逃课博弈）。

而真正良性且高效的模式，是 “健身教练与学员” 的契约关系：

  • 学员（学生）：是真正想要强身健体、掌握本领的人。挥汗如雨、编码写文档、犯错调试的必须是学生自己；
  • 教练（老师/助教）：具备深厚的工程实践经验，制定科学的训练计划与严谨的评估标准，不留情面地指出动作变形与代码缺陷，并给予高频、及时的反馈。

面对困难作业的态度抉择：
如果老师布置的作业对我来说难度较大、一时没有头绪，我的选择是：
C. 向老师、助教和同学请教，花更多时间，查阅官方资料并逐步拆解，把作业全部完成。
说明：困难作业往往正好处在认知的“学习区/拉伸区”，是能力蜕变的最佳契机。逃避和糊弄只会把知识漏洞留给期末和未来。我会先独立思考、阅读文档、动手尝试，带着清晰的尝试过程向老师与同伴请教，直到真正攻克难关。

③ 规范引用、合理借鉴与抄袭剽窃的区别

研读邹欣老师《作业的底线》后，我对学术与工程的底线边界有了明确把握：

行为类型 文档 / 博客层面 代码 / 项目层面 本质差异
合理引用与二次开发（合规倡导） 明确注明原文链接与作者，使用引用语法（>）包裹直接引句；结合自身实践写出增量思考与反思，非大段复制。 合理引入开源类库或参考官方示例代码；在代码注释中清晰标注来源链接；在遵循开源协议的前提下进行二次开发，且核心业务有自主实现。 承认前人贡献，以公开透明的方式站在前人肩膀上创新，产出了属于自己的新思考、新代码。
抄袭与剽窃（违规严惩） 直接复制他人的博客、文章或实验报告；不加出处标注，或微调语句顺序冒充原创。 直接克隆或复制同学/往届/网络完整项目代码；仅通过替换变量名、微调函数顺序或删除注释来伪造独立完成假象。 窃取他人智力劳动成果，伪装为自己的产出，没有增量思考，违背学术诚信与契约底线。

在后续的学习与作业中，我将严格遵守课程引用规范，凡参考代码必注出处，凡借鉴思路必做说明，筑牢学术品格防线。

（3）未来发展选择、优劣势与本学期规划

1. 未来发展选择

结合自身兴趣与专业发展趋势，我的短期与长期规划为：在校期间扎实提升工程实战能力与算法基础，争取头部互联网或科技企业工程研发实习。无论走向科研深造还是工业研发，扎实严密的软件工程素养、代码掌控力与文档规范都是无可替代的硬实力。

2. 个人优势与劣势剖析

  • 优势：
    1. 专注力强，坐得住冷板凳：能够长时间处于深度工作状态，面对晦涩的文档或顽固的 Bug 具备足够的耐性；
    2. 善于复盘，条理性好：习惯总结规律，注重知识体系化，做事有条不紊；
    3. 具有良好的学术与工程敬畏心：追求代码规范与清晰架构，不满足于代码“勉强跑通”。
  • 劣势：
    1. 工程实战积累偏浅：过往以小型课程作业为主，缺乏全流程团队项目的真实磨砺，对技术债、大型系统重构体会不足；
    2. 测试与质量意识薄弱：以往偏重业务功能的快速实现，缺乏系统化的单元测试、集成测试与自动化 CI 经验；
    3. 技术表达与公开汇报有待加强：在团队讨论中倾向于被动执行，主动汇报方案、撰写架构演进文档的能力需要刻意打磨。

3. 本学期整体规划

  1. 课程核心任务：以软件工程课程为轴心，全力完成个人项目、结对编程与团队大作业，将每次迭代视为一次真正的工业化交付实战；
  2. 技术栈深耕：夯实核心编程语言基础（C++/Java/Python），掌握 Git、Docker、自动化测试工具链，告别“玩具代码”；
  3. 长期写作沉淀：按时在博客园输出高质量复盘随笔，做到图文并茂、结构清晰、逻辑严谨；
  4. 时间精力平衡：严格制定周度计划，在专业课核心实验、课余算法刷题与未来规划之间保持张弛有度的节奏。

（4）本课程学习计划与 WOOP 完整规划

1. 对本课程的期待与学习态度

我期待本课程能打破以往“考前背名词、实验划水交差”的传统教学惯性，成为一门真正有对抗、有协作、有产出、有严苛反馈的硬核实战课。我希望在这里：

  • 亲历软件从“需求调研、原型设计、模块解耦、结对编码、测试驱动、持续集成到发布维护”的完整生命周期；
  • 在高标准的代码审查（Code Review）中直面自己的坏味道与工程缺陷；
  • 学会在团队协作中化解分歧、统一接口、协同作战。

2. 代码量现状与统计

截至目前，我的累积代码量统计如下（排除生成的模板文件与空行注释）：

  • C/C++：约 1,800 行（主要分布于大一程序设计基础、数据结构实验及底层算法练习）；
  • Python：约 1,200 行（主要分布于脚本工具、基础数据处理与课程 Demo）；
  • Java / Kotlin：约 5,800 行（主要分布于练习项目与实习开发项目）；
  • 累计有效代码量：约 8,800 行。

客观评估，现有代码量仅仅达到了入门练手门槛，距离一个能够独立交付企业级模块的工程师（通常需要数万行规范代码与测试用例的浸泡）仍有明显差距。

3. 时间投入与代码增量目标

  • 每周时间投入：预计每周投入 12~15 小时（包含课堂互动、课后研读、结对编码、团队 Scrum 站会与博客复盘）；
  • 面对以往时间浪费的选择：我选择 D. 比以前的课要多很多，直到达到目标为止。既然选择把这门课当作工程能力的蜕变战场，就绝不吝啬汗水与精力；
  • 课程结束代码量目标：在完成个人项目、结对项目与团队项目的全过程中，新增高质量工程与测试代码 3,500 ~ 4,000 行，平均每周净增有效代码 250 行左右（重点在于单测覆盖与模块化设计，而非盲目堆砌代码行数）。

4. WOOP 四步完整规划

  • Wish（愿望）：
    在软件工程课程结束时，熟练掌握现代软件工程全流程规范，不仅能独立交付高质量模块，更能与团队通力合作开发出一款具有真实实用价值的软件项目；高质量完成全部博客随笔，形成清晰的个人工程思维体系。
  • Outcome（最佳结果）：
    彻底告别面对项目无从下手的迷茫状态；在 GitHub 上沉淀出规范、整洁且带全量 CI/单测的开源仓库；在团队协作中成长为靠谱、能够独当一面的技术核心；在博客园积累数万字的深度复盘文稿，为考研/求职筑起坚实的技术壁垒。
  • Obstacles（核心障碍与最可能失败的因素）：
    1. 多重任务并行带来的时间冲突：学期中专业课密集、考研复习或实习准备可能导致精力透支；
    2. 调试阻碍引发的挫败感与拖延心理：遇到极其诡异的 Bug 或复杂的环境配置时，容易产生烦躁情绪，导致进度堆积直至 DDL；
    3. 团队沟通摩擦与目标不一致：团队协作中可能出现职责不清、有人搭便车或需求反复变更的局面。
  • Plan（应对方案：If-Then 策略）：
    1. If 专业课任务与软工作业在某周严重重叠，Then 我将在每周日晚利用四象限法则对本周任务排定优先级，把大任务拆解为每天 1~2 小时的可量化小模块，每日清零，杜绝临阵磨枪；
    2. If 某个 Bug 连续排查超过 1 小时仍无突破、心态开始焦躁，Then 我将立刻停下键盘，起身喝水休息 10 分钟，随后使用“橡皮鸭调试法”向助教或同伴梳理调用栈，并在 issue 中详实记录重现步骤；
    3. If 团队开发中出现接口定义模糊或进度脱节，Then 我将主动在 GitHub Projects 上更新任务状态，在次日敏捷站会中明确对齐输入输出接口与交付时限，以客观事实驱动协作；
    4. If 编码完成但产生敷衍心理、不想写单测与注释，Then 强制启用分支保护策略，要求必须在测试用例覆盖率达标、Linter 无告警后方可提交 PR 合并。

三、高质量提问与课程反馈

认真研读邹欣老师所著《构建之法：现代软件工程》并践行《提问的智慧》，结合具体章节观点与个人的学习开发体会，提出以下 5 个有据可循、有深度思考的问题：

问题 1（出自：第 1 章 软件工程概论 - 1.2 软件工程是什么）

  • 教材观点引用：书中指出软件工程的目标是在给定的约束条件下（时间、人员、预算、技术），创造“足够好”（Good Enough）的软件。
  • 我的问题：在学术研究/算法探索型项目与工业级商业软件之间，“足够好”的边界该如何动态权衡？作为尚未进入工业界的本科生，我们在完成课程项目时，应该在多大程度上为了追求“足够好”的交付时间，而适度妥协架构的完美性（如为了快速出原型而背负技术债务）？
  • 个人思考与困惑：在以往的练习中，我经常陷入两个极端：要么试图在一开始就设计出无比完美的架构，导致分析麻痹、迟迟不能动手；要么为了在 DDL 前跑出结果而胡乱拼凑代码，导致后期稍有变动就全盘崩塌。我很想了解一线工程师如何在“敏捷交付原型”与“控制技术债务”之间找到那个科学的平衡点。

问题 2（出自：第 2 章 个人技术和流程 - 2.3 效能分析工具）

  • 教材观点引用：书中引用了著名的格言“过早的优化是万恶之源”（Donald Knuth），强调不要凭直觉进行性能优化，而必须依靠 Profiler 工具定位真实瓶颈。
  • 我的问题：在系统初始架构设计与数据流定义阶段，“预留扩展性与性能考量”和“过早优化”的具体界限在哪里？我们如何避免把“合理的防御性设计”误判为“过早优化”？
  • 个人思考与困惑：有时我在写代码时，为了避免未来可能的性能瓶颈，会选择较为复杂的缓存策略或异步消息设计，但往往导致当前代码复杂度激增、调试极为痛苦；可如果不做预留，后期重构又近乎重写。在实际工程中，架构师是如何界定“必须提前规划的基础设施”与“应推迟到后续演进的微观优化”的？

问题 3（出自：第 3 章 软件工程师的成长 - 3.2 软件工程思维方式）

  • 教材观点引用：书中剖析了初学者常见的思维误区之一是“分析麻痹”（Analysis Paralysis）——一味做需求分析和理论调研，迟迟不肯动手写第一行代码。
  • 我的问题：在面对一个从未涉足的新技术栈或复杂未知业务时，如何通过量化指标来判断前期的“技术调研”是否已经饱和、应当立即进入编码阶段？
  • 个人思考与困惑：在过往的学习中，每当要使用新框架时，我总感觉自己还有很多文档没看全、很多底层机制没搞透，因而不敢下笔编码；但真正动手后又发现许多前期纠结的细节在实践中根本不是关键。怎样才能建立一套高效的“探针式原型验证（Spike Solution）”工作流？

问题 4（出自：第 8 章 需求分析与第 6 章 敏捷流程）

  • 教材观点引用：敏捷流程强调 Daily Scrum（每日立会）、快速迭代、根据用户反馈持续微调需求与燃尽图。
  • 我的问题：对于学生团队而言，各成员均有繁重的其他课程与考核压力，难以做到像全职团队那样每日集中办公与高频同步。高校环境下的软工团队，应当如何对敏捷开发模式进行“本地化改良”，以防止每日站会沦为走过场的形式主义？
  • 个人思考与困惑：根据往届学长的反馈，很多学生团队在执行敏捷流程时，往往前两周热情高涨，随后便因期中考、实验报告等外部干扰而导致看板荒废、燃尽图失效，最终在期末沦为“突击瀑布模型”。学生团队究竟该如何设计容错度更高的迭代节奏？

问题 5（出自：第 16 章 创新与第 17 章 人、绩效和职业道德）

  • 教材观点引用：书中强调颠覆性创新往往是九死一生的，很多时候在既有成熟生态上的“渐进式改进（Incremental Innovation）”更具生命力与商业可行性。
  • 我的问题：在高校软件工程大作业的选题中，我们应该优先选择一个“确定性极高但缺乏新意”的传统题目（如各类信息管理系统、基础电商系统），还是应当大胆选择一个“具有探索价值但随时可能因技术攻关失败而延期”的创新题目？课程评估是如何平衡“工程交付完整度”与“技术创新探索度”的？
  • 个人思考与困惑：追求创新往往伴随着极高的踩坑风险，对于时间和精力受限的本科生团队而言，过度求新容易导致连一个最小可用原型（MVP）都交不出来；但若纯粹选择稳妥题目，又失去了这门课挑战工程极限的初衷。

课程反馈态度选择

面对教学过程中的双向沟通与反馈机制，我的选择是：
D. 经常提问题，平时就经常给老师和助教提反馈。
说明：教学绝不是老师单向输出的孤岛。如同健身教练需要实时观察学员的受力反馈一样，及时的沟通与反馈能够让老师和助教第一时间掌握大家的痛点与进度，使教学张力达到最优。我会在日常学习中主动记录疑惑，在博客、课堂和 issue 中坦诚表达思考，主动配合教学流程的迭代。

四、前车之鉴——前辈文章阅读感悟

研读了课程推荐的豆瓣经典讨论帖中前辈们的技术生涯复盘，我深受启发，提炼出以下三点最核心的自省感悟：

感悟一：跳出 DDL 焦虑，筑牢“重要但不紧急”的核心护城河

  • 阅读链接：四象限时间管理与反思
  • 深刻感悟：
    文章剖析了很多人长期被“紧急事件”（如明日截止的作业、即将到来的小测）推着走的困境，整天疲于奔命却没有任何实质性的能力沉淀。反观我自己，在大一、大二也曾陷入这种被动应付的恶性循环——为了赶各类截止日期，只要代码一跑通就立刻关闭编辑器，长期忽视了那些“极其重要却不紧急”的事：深入研读计算机底层原理、系统化刷算法题、补齐单元测试、规范整理技术博客、重构低质代码。
    正是这些在平时“不紧急”的事情，决定了未来在考研复试、技术面试中能否从容应对。从本学期开始，我将严格运用“时间四象限法则”，在每周日程中强制为“重要不紧急”的技术阅读与复盘留出固定整块时间，变“被动救火”为“主动投资”。

感悟二：打破科班光环盲目崇拜，用代码实战穿透纸上谈兵

  • 阅读链接：科班出身的误区与动手实践反思
  • 深刻感悟：
    作者在文中深刻反思了计算机科班教育中的脱节现象：很多人自恃掌握了高等数学、离散数学、数据结构等名牌课本理论，考试成绩名列前茅，但一旦面对真实的工程环境，连基本的版本控制不会用、依赖装不上、报错看不懂、千行规模的项目逻辑支离破碎，最终在求职市场上被拥有丰富项目经验的非科班同学降维打击。
    这给我敲响了警钟：科班的学籍不是技术能力的保证书，“Talk is cheap, show me the code” 才是软件世界的唯一硬通货。学懂了概念和具备工程交付能力之间隔着千山万水。我绝不能仅仅满足于在试卷上写对算法伪代码，而必须珍惜软件工程这门课的每一次代码敲击，用真实的工程项目去检验、打磨并深化书本上的理论知识。

感悟三：建立“思维快照”，以持续自省打破低水平重复

  • 阅读链接：思维快照与自省的习惯
  • 深刻感悟：
    文章作者提到了定期为自己的技术思维拍一张“思维快照（Mental Snapshot）”的做法——随时记录当下的技术困惑、设计抉择与踩坑思考，隔一段时间回头审视。这与刘未鹏老师倡导的写博客理念高度共鸣。人类的大脑具有极强的遗忘机制，如果不及时记录，几个月后我们甚至无法回忆起自己曾经犯过的愚蠢错误，进而不断在同一个低水平陷阱里打转。
    写博客与技术随笔，本质上就是为自己的心智成长留下可追溯的 Git Commit 记录。通过定期回看以前的博客，我们能清晰看清自己认知框架的演进轨迹。本学期，我将坚持把博客园随笔作为自己的“思维快照档案馆”，真实记录每一次挫折与顿悟，在持续自省中实现跨越式成长。

五、博客园与 GitHub 作业材料

1. 博客园默认 Markdown 编辑器设置

为了确保后续所有随笔格式统一、排版规范，我已在博客园后台将“默认编辑器”切换为 Markdown 格式。

Markdown编辑器设置截图

2. GitHub 个人仓库链接与配置

为了承载本学期所有的代码演进、个人项目、结对项目与工程作业，我已在 GitHub 上完成了个人主页配置并创建了专属的课程作业仓库：

GitHub个人仓库截图

3. 学习规范与排版说明

在完成本次作业的过程中，我认真研读并践行了以下技术规范：

  1. 中文文案排版指北：严格保持中文字符与英文字符、数字之间添加空格（如 Markdown 排版、Python 3.10、Git 分支），正确使用全角标点符号，杜绝中英文标点混杂；
  2. 结构化层级排版：全面运用 Markdown 标题层级、引用块、对比表格与有序列表，使文章视觉逻辑清晰、重点突出；
  3. 提问与沟通规范：严格遵循《提问的智慧》，提出问题前先自行查阅官方文档并做排除法尝试，提问时提供详实的环境、日志与复现步骤；
  4. Git 与工程底线规范：掌握基础 Git 工作流，后续所有项目将坚持规范的 Commit 语义与分支管理，坚决守牢学术诚信底线。

本篇随笔全文字数约 6,500 字，完稿于 2026 年 9 月。以此作为软件工程课程的扬帆起点，道阻且长，行则将至！

posted @ 2026-09-05 14:28  IntZ  阅读(26)  评论(0)    收藏  举报