3124004053第一周作业

这个作业属于哪个课程	https://edu.cnblogs.com/campus/gdgy/Class56-Grade2024-CS/
这个作业要求在哪里	https://edu.cnblogs.com/campus/gdgy/Class56-Grade2024-CS/homework/15692
这个作业的目标	写一篇随笔

1.基本信息

大家好，我是陈梓铤，来自计算机科学与技术5班。

• 兴趣爱好：除了编程，我热爱听音乐 和 打乒乓球。
• 技术兴趣：对AI全栈开发有浓厚兴趣，目前正在学习中。

我的闪光点：持续学习与坚持

在我看来，我最大的优势是 快速自学的能力和学习过程中保持耐心。

2. 现状、经验和计划

（1）专业选择与技能差距

为何选择这个专业？

我选择计算机科学与技术专业，核心驱动力是对“创造”与“解决实际问题”的兴趣。高中时接触到简单的编程，看到几行代码能形成交互逻辑并产生实用价值，这种从无到有的构建过程深深吸引了我。进入大学后，我愈发认识到软件正在定义世界，这个领域需要持续学习，与我乐于接受挑战的性格相符。

技能差距分析

要成为一名合格的IT专业毕业生，我意识到自己离全面发展的要求还有明显差距。我结合在研发中心工作室的项目实践（如实验教学平台、AI发票识别平台），从课程提供的技能调查表中抽取了以下5项我认为至关重要、且与我的实战经验紧密相关的技能进行分析：

技能项	当前水平 (0-9)	目标水平 (0-9)	提高计划（至少5项）
需求对齐和代码健康度	5	7	1. 在开发前进行更细致的需求评审，梳理业务流程图。 2. 学习并实践代码整洁之道，定期进行代码重构。 3. 在团队中推动代码审查（Code Review）并参与互审。 4. 学习并遵守团队代码规范与Git提交规范。 5. 定期进行代码复杂度分析与优化。
手动掌控力和底层原理	5	7	1. 深入阅读React或Vue框架核心源码，理解其diff算法与渲染机制。 2. 学习浏览器底层渲染原理与事件循环模型。 3. 在项目中遇到框架层面问题时，尝试从源码层面定位。 4. 学习JavaScript引擎（如V8）的基础工作原理。 5. 阅读《深入理解计算机系统》相关章节。
验证深度和测试覆盖	4	7	1. 系统学习单元测试、集成测试方法（如Jest、Vitest）。 2. 在项目中为关键工具函数和业务组件编写单元测试。 3. 了解测试驱动开发（TDD）理念并尝试在小模块中应用。 4. 学习端到端测试工具（如Playwright/Cypress）的基本使用。 5. 建立“先写测试、再写功能”的思维习惯。
工程复现性和构建完整度	5	7	1. 深入学习Webpack/Vite构建原理，编写自定义Loader/Plugin。 2. 规范项目工程化配置（如ESLint、Prettier、环境变量管理）。 3. 学习并实践CI/CD（持续集成/部署）的基本流程。 4. 熟悉Docker容器化技术，尝试构建标准开发环境镜像。 5. 建立项目文档化习惯，确保新成员可快速上手。
自动化进化闭环与数据飞轮	4	6	1. 学习使用自动化工具（如GitHub Actions）完成项目的自动构建与部署。 2. 了解前端监控体系，尝试在项目中接入错误追踪（如Sentry）与性能分析工具。 3. 阅读相关文章，理解数据驱动产品迭代的理念。 4. 学习基本的A/B测试原理，并在个人项目中模拟实践。 5. 建立“开发-测量-学习”的反馈循环意识。

通过这份自评，我清晰地认识到自己在工程化深度、测试意识和底层原理方面仍有较大提升空间。我会将上述提高计划落实到本学期的学习与项目实践中。

（2）阅读心得与思考

a) 为何要来上课并且认真参与？

阅读了参考文章中学生的思考以及下方评论后，我深受触动。我认为上课的意义远不止于获取知识。课堂提供了一个“引导性场域”和“即时反馈”的环境。老师的点拨可以帮我快速抓住重点，避免在细枝末节上耗费过多时间；与同学的讨论能激发不同角度的思考。认真参与是对自我时间和教育投入负责的表现，也是形成“主动学习”习惯的关键一步。

b) 师生关系与应对困难

在大学里，我体验过“权威型”和“放养型”的师生关系。我希望这门课是“健身/教练”式的师生关系：老师是制定训练计划、提供专业指导、督促并鼓励我们的教练，而我们是需要主动流汗、反复练习的学员。

如果老师布置的作业对我来说有些困难，我会毫不犹豫地选择 C. 向老师和同学请教，花更多时间，把作业全部完成。这与我开发项目时的经验一致——遇到棘手问题（如实现LRU缓存或分片上传），正是通过查阅文档、寻求帮助和反复调试才得以突破的。困难是成长的必经之路。

c) 引用、参考与抄袭、剽窃的区别

我认为，两者最本质的区别在于是否“尊重并明确标注他人的智力贡献”。

• 引用与参考：是在自己独立思考和工作的基础上，借鉴他人的观点、数据或代码片段来支撑自己的论述或实现，并通过规范的引注方式清晰标明来源。这是学术和行业诚信的基石。

• 抄袭与剽窃：是未经转化或标注，将他人的思想、作品或代码直接作为自己的成果呈现，意图让他人误以为是原创。

在实际开发中，使用开源库（如antd、Vite）是合法的参考，但必须遵守其许可证条款。对于参考的代码片段，我习惯在注释中注明出处。我会仔细了解老师在这门课中的具体要求，并严格遵守学校关于学术不端行为的所有规定。

（3）未来规划、优势劣势与学期规划

我的选择：成为一名优秀的全栈/前端工程师

在阅读了前人的经历（特别是那些在职场中摸爬滚打的大佬故事）后，我更坚定了自己的方向。我希望毕业后能进入一流的互联网公司或软件企业，从事软件工程相关工作。

优势与劣势分析：

维度	具体内容
优势	1. 实战经验相对丰富：有多个真实项目的前端开发经验，对Vue、React及工程化流程有直接理解，能更快适应实际工作节奏。 2. 工具意识强：善于利用AI辅助开发工具并具备代码校验能力，这符合提升开发效率的行业趋势。 3. 主动性较高：在项目中会主动承担难点任务，有解决实际问题的驱动力。
劣势	1. 计算机理论基础不够扎实：算法、数据结构、计算机网络等核心知识掌握不深，长期来看会成为职业发展的瓶颈。 2. 技术广度不足：技能主要集中在前端，后端，对数据库、系统设计等领域缺乏深入实践，限制了解决复杂全栈问题的能力。

本学期的具体规划：

1. 深化前端技能：精研一个框架，理解其核心源码与最佳实践，提升至能通过一线公司面试的水平。
2. 夯实基础：坚持每周算法练习，并系统复习网络、操作系统等核心课程知识。
3. 拓展技术边界：通过学习Node.js或Python，尝试完成一个简单的全栈项目，理解前后端交互的全流程。
4. 高质量完成本课程：通过课程项目，完整经历软件工程的需求分析、设计、开发、测试等阶段，建立规范化的开发与协作意识。

（4）课程计划、时间投入与WOOP规划

我的期待与计划：

我期待这门课程能超越单纯的技术教学，真正培养我们的“软件工程思维” ——即如何分析需求、设计架构、团队协作、保证质量。我计划通过积极参与课程项目，争取在一个完整的团队项目中担任核心开发角色。

参考了美国本科、中国软件工程本科等教学案例后，我特别认同那些强调项目驱动、团队协作和过程管理的教学模式。我希望这门课也能让我们经历一个接近真实工业界的开发流程。

代码量现状与目标：

• 目前代码量：结合我的项目经历（实验教学平台、AI发票识别平台等），我预估目前的代码量约为 8000 - 10000行（主要为HTML/CSS/JavaScript/TypeScript，以及Vue/React框架代码）。
• 一流公司的门槛：我认为要具备入职一流软件公司（如BAT、TMD等）的资格，需要 2万行以上 的扎实编码经验，并深入理解至少一个完整技术栈。
• 高校教学科研工作：这更侧重于理论深度、算法创新和论文撰写，代码量并非核心指标，但需具备扎实的工程实现能力来验证想法。通常需要能独立完成实验原型系统的开发。

时间投入与决心：

我选择 D. 比以前课要多很多，直到达到目标为止。前两年的学习让我明白了深度投入的重要性，这门课是我将知识与实践紧密结合的关键机会。

我计划平均每周拿出 15 - 18小时（包含上课时间）投入到这门课程中。

课程代码量目标：

我计划在本课程结束时，新增代码量 至少5000行，平均每周完成 300 - 500行 的有效代码。

WOOP计划

• Wish（愿望）：在本课程结束时，能作为核心成员，完成一个具有完整前后端、功能完善且用户体验良好的Web应用项目，并在团队协作中展现出良好的工程化素养。

• Outcome（结果）：项目获得优秀成绩，成为我简历上极具说服力的项目亮点。我对软件工程全流程的理解和实践能力显著提升，为暑期实习面试打下坚实基础，获得理想公司的实习机会。

• Obstacle（障碍）：

  • 内部障碍：面对复杂bug或新技术概念时，容易产生畏难情绪，导致拖延，浪费大量时间在“心理建设”而非行动上。
  • 外部障碍：其他课程作业和工作室的项目任务可能会挤占时间，导致无法保证固定的、深度的学习与编码时段。

• 最可能的失败因素：时间管理与精力分散。具体表现为在多种任务间频繁切换，导致深度工作时间不足，核心课程任务被推迟。

• Plan（计划）：

  • 如果 感觉任务庞杂无从下手，那么 我将任务分解为可执行的子任务列表（如“设计数据库表结构 -> 编写API文档 -> 实现登录页面”），并利用番茄工作法（每专注25分钟，休息5分钟）逐个完成。
  • 如果 其他事务突然增多，感觉时间紧张，那么 我将使用日历工具提前进行周规划，优先保障本课程的“不可压缩时间”（例如，固定每周二、四晚上8-10点为课程项目时间）。
  • 如果 在调试一个bug上卡住超过1小时，那么 我将把问题详细记录，暂时搁置去完成其他模块，或带着具体问题在答疑时间请教同学或助教，避免陷入低效的死循环。

3. 提有质量的问题，给认真的反馈

快速阅读《构建之法》前几章后，这本书给我最深的感受是：它不像传统教材那样堆砌理论，而是用大量贴近实战的场景和对话，把软件工程的核心理念讲得生动有趣。但也正因如此，书中很多观点与我有限的项目经验产生了碰撞，也激发了不少困惑。以下是我梳理出的5个问题。

---

问题一：关于“软件 = 程序 + 软件工程”——工程化的临界点在哪里？

我看了这一段文字：“软件 = 程序 + 软件工程”，书中进一步推论：“软件企业 = 软件 + 商业模式”。

这个等式看似简单，却让我反复思考一个问题：从“程序”到“软件”的跨越，临界点究竟在哪里？

我在研发中心工作室参与过多个项目，对这些“看不见的工程”深有体会——环境配置不一致导致部署失败、多人协作时代码互相覆盖、测试环境和生产环境数据库版本不同……每一件都不是“程序”本身的问题，但每一件都能让项目翻车。正如一位读者所言：“能跑的代码 ≠ 能用的产品。”

但我还是不太懂：对于学生项目或小型团队项目，我们往往只有3-5个人、开发周期只有几周。在这种情况下，如果严格按照“软件工程”的标准来做（完整的需求文档、规范的变更管理、全面的测试覆盖），会不会反而导致项目无法按时交付？书中提到软件工程是“复杂度到了就必须有”的，但作为学生，我该如何判断当前项目是否已经到了那个“临界点”？有没有一些量化的判断标准，比如团队规模、代码行数、预计用户量等？

问题二：关于“足够好”的软件——如何把握取舍的尺度？

我看了这一段文字：软件工程的目标不是“完美的软件”，而是“足够好”的软件。书中提到四个变量——范围、时间、成本、质量——互相牵制，工程的本质就是在约束之间做取舍。

读到这，我立刻联想到自己在发票识别平台项目中的经历：当时为了实现一个“完美的”二维码加密签到功能（基于crypto实现加密，防止扫码信息被盗取），我花了两天时间反复优化加密逻辑，但最后发现用户最关心的其实只是“签到能不能成功，别卡顿”。正如一位工程师所反思的：“用研究思维干工程的活——总想一步到位，结果永远在重构，永远没交付。”

我有这个问题：“足够好”固然是一个务实的理念，但在实践中，我该如何系统性地判断“什么程度才算足够”？是凭经验和直觉，还是有可量化的评估方法？比如，对“代码健康度”而言，多少测试覆盖率算“足够”？对“用户体验”而言，页面加载时间多少以内算“足够”？我担心没有明确标准的话，“足够好”很容易沦为“差不多就行”的借口。

问题三：关于团队合作——无法选择队友时该如何应对？

我看了这一段文字：书中第四、五章用了大量篇幅讨论两人合作和团队合作的重要性，包括代码规范、结对编程、代码复审等。

我有这个问题：书中似乎默认了团队成员是经过合理筛选的、大家目标一致的。但在现实中（尤其是大学课程项目中），我们往往无法自主选择队友，成员的技术水平、责任心、投入度可能参差不齐。

有读者也表达了类似的困惑：“任何没有团队准入机制就堂而皇之跟你大谈团队合作重要的组织或个人，都是流氓行为。大学很多时候自己单干和团队协作是不能够自己选择的。遇到猪队友，那只会给自己徒增‘游戏’难度。”

我的困惑是：在团队组成无法选择的情况下，我们该如何进行有效的团队合作？如果遇到“划水”或能力明显不足的队友，是该主动向老师反映重新组队，还是硬着头皮帮他完成他的部分以保证项目质量？在这种情况下，“结对编程”还有意义吗？

问题四：关于敏捷流程——如何应对“伪敏捷”的风险？

我看了这一段文字：第六章介绍了敏捷流程的核心理念，包括“尽早并持续交付有价值的软件以满足顾客需求”“欢迎需求的变化”等原则。

我有这个问题：书中描绘的敏捷流程非常理想化——团队成员高度自律、沟通频繁、客户深度参与。但在学生项目中，这些条件往往都不具备。更让我担心的是，敏捷开发中的“快速迭代”“频繁发布”等口号，会不会被一些人利用来掩盖“缺乏规划”和“没有设计”？

正如有读者批评的：“敏捷’是否等同于速成？现在人都是对短期能达到目标或获得奖励的事更有兴趣更能坚持的。恕我直言，这是为了迎合绝大多数国人急功近利急于求成的心态。一味的追求速成的人不都是‘伪努力者’吗？21天学会编程、一个月助你过英语四六级等课程层出不穷……捷径有，但真正能花别人1%的时间学到100%的知识是不太切合实际的。”

我的困惑是：对于学生团队，我们该如何区分“真敏捷”（快速响应变化、持续改进）和“伪敏捷”（没有规划、随意改需求、逃避设计文档）？在实际操作中，有没有一些可落地的底线标准，帮助团队避免陷入“伪敏捷”的陷阱？

认真反馈

既然这门课倡导的是“健身/教练”式的师生关系，那么作为学员，主动提问和反馈就是我的责任。我选择 D. 经常提问题，平时就经常给老师和助教提反馈。

在上面的提问中，我尝试遵循“指出章节 -> 提供上下文 -> 结合自身经验 -> 阐明困惑”的框架。我认为好的提问本身就是一种学习——它逼着你去思考“我到底哪里不懂”“我为什么会有这个疑问”。本学期我计划在课程中至少再提出3-5个深入的问题，并认真对待每一次课程反馈问卷，因为只有真实的反馈才能让教练（老师）知道学员（我们）的真实状态，从而调整“训练计划”。

4. 前车之鉴

在阅读了《IT小小鸟的故事》中几位前辈的分享以及其他技术前辈的经历后，我最大的感受是：前人所走过的弯路、所总结的经验，对我们这些后来者而言，是一笔极其宝贵的财富。 他们的故事让我看到了迷茫的普遍性，也让我意识到行动、思考和坚持才是破局的关键。以下是我针对其中几篇文章的具体感想。

---

关于思维快照与自省：向过去的自己学习

阅读文章：徐宥：掉进读书的兔子洞

徐宥在文章中提到，他有一个从高中就开始的习惯：“把每天胡思乱想的东西记在一个笔记本上，作为思维快照，并常常翻回去自省，看看过去和现在的变化。” 这个习惯让我深受触动。

我的感想：
读完徐宥的经历，我立刻想起了自己断断续续的记录习惯。我也有一个本子，但往往只在心血来潮或情绪低落时才翻开，写下的内容多是情绪化的宣泄，很少像他那样有意识地记录和整理自己的“知识索引”与“思维轨迹”。他在大三迷茫时期，尽管像“掰玉米棒子”一样读书，却依然坚持记笔记。这让他到大四时，能“按图索骥地去深入强化当时如无头苍蝇般乱看的一些书”。

这个习惯给了我很大的启发。记录本身不是目的，通过记录来观察自己的思考过程、建立知识间的联系，并在未来能够回溯和复用，这才是核心。 我计划从现在开始，更系统地建立自己的“思维快照”：不仅仅记录待办事项，更要记录对某个技术问题的理解、读某篇博客后的灵感，以及某个项目中犯过的错误。我相信，半年后回头翻阅时，这些记录会让我清晰地看到自己的成长轨迹，正如徐宥所体会到的那样。

---

关于“科班”困惑与深度积累：从“我知道”到“我做到”

阅读文章：刘帅：在失望中寻找希望

刘帅的故事是另一个让我产生强烈共鸣的例子。他是“科班出身”，学过所有核心课程，但他坦言：“我是科班——却没学懂计算机。” 他描述自己本科时像高中一样机械学习，满足于完成作业和拿到奖学金，却缺乏主动思考和深入实践，直到在清华旁听朱仲涛老师的“数据结构”课时，被那种当场从0开始实现复杂算法的能力所“震撼”。

我的感想：
这篇文章让我感到一种“后怕”。因为我在某种程度上，似乎正走在刘帅描述的老路上。作为计算机专业的学生，我也在学数据结构、操作系统、编译原理这些课程。有时我也会满足于理解概念、通过考试，而没有深究“我能否从零实现它”。刘帅的反思点醒了我：“计算机专业需要大量时间，需要付出大量精力，也需要极大的耐心。但大部分像我一样的80后都做不到。而做到的，现在几乎没有例外地都找到了很好的工作。”

结合我自己的项目经历，我确实写过不少前端代码，但当我被问到“如果不用lucence，你怎么办？”或者“Junit哪些地方不好？”这类问题时，我也会像刘帅在“完美时空”面试中那样感到崩溃。这暴露了我“知其然不知其所以然”的弱点。因此，我更要警惕陷入“机械完成作业”的陷阱，必须像他后来努力改变思维习惯那样，刻意训练自己在学习每门课程时，问自己：“我有没有从0实现它的能力？它背后的核心思想是什么？”

---

关于行动与坚持：在持续行动中找到方向

阅读文章：一个程序猿的生命周期 系列

这个系列博客的作者（一位经验丰富的程序员）记录了自己从技术开发到尝试农业、再到重新回归软件领域并组建团队的曲折历程。他的经历中充满了“中年危机”的思考和对“35岁现象”的讨论。

我的感想：
这位前辈的经历，从另一个维度展现了程序员职业生涯的复杂性。如果说前两位作者的故事是关于如何学好专业，那么这位作者的故事是关于如何面对漫长职业生涯的起伏。他尝试农业又回归软件，经历了公司动荡，最终在“改变中寻找机会”。这让我意识到，职业生涯不是一条直线，而是一个需要不断调整和重新出发的过程。 他提到的“生态合作与自主可控”的案例——一个团队花费一年开发效果不理想——也印证了软件工程中需求对齐、工程复现性和构建完整度的重要性，这正好呼应了我之前技能自评中的弱项。

他的经历也提醒我：迷茫和挫折是常态，重要的是不停止行动。 徐宥通过大量阅读和做笔记来对抗迷茫，刘帅通过考研和实习来寻找方向，而这位前辈则通过在不同领域尝试和坚持来寻找新的可能。这让我对自己的未来多了几分坦然：不必害怕选择，重要的是在每一次选择中都全力以赴，并持续积累。

---

综合感悟

这三篇文章从不同角度给了我警示和启发：

文章	核心启示	对我的警示
徐宥	建立“思维快照”，记录并定期反思自己的思考轨迹与知识索引。	不能只埋头做事，要定期复盘，建立自己的知识体系。
刘帅	“科班”不等于“学懂”，必须主动深入实践，从“知道”到“做到”。	警惕机械学习，在每次作业和项目中追求更深层的理解和实现。
程序猿的生命周期	职业生涯充满变数，需要持续行动、调整方向，在改变中寻找机会。	不必追求一条完美的直线，重要的是保持行动力和学习力。

这些“前车之鉴”让我更加清晰地认识到，我现在正站在他们曾经站过的起点上。他们的弯路和成功，都成为了我可以借鉴的地图。此刻我的任务，就是像他们一样，用持续的思考、扎实的行动和诚实的记录，去走好自己的路。

我已按课程要求，在 GitHub 上创建了与 ID 一致的仓库：

网址：https://github.com/Zztt417/Zztt417