软件工程第一次作业随笔

一、介绍自己，建博客

我是广工计算机科学与技术专业的一名学生。这次在博客园开通个人博客，既是课程要求，也是给自己建立一个持续记录学习过程的习惯。

写博客确实花时间，整理思路、组织语言、调整排版，都比想象中要费功夫。但我认同“写博客很有意义”这个观点——很多知识看的时候觉得懂了，真正要写出来讲给别人听，才会发现理解得其实不够透彻。把思考过程用文字固定下来，既便于自己日后复盘，也为可能的讨论留下空间。

欢迎同学们就我文章中的观点提出不同意见，能够在讨论中被纠正或完善的观点，本身就有价值。

我的闪光点

如果跳出考试成绩的评价体系，我认为自己比较突出的能力是长期坚持一件需要耐心的事。高中到大学这几年，我一直保持着写日记和做周报的习惯，把每周学到的东西、遇到的坑、解决的问题简单记下来。这个习惯看起来不起眼，但坚持了三年多之后，我发现自己对比其他同学最大的差别是：遇到同样的错误，我不会重复踩坑，因为有记录可查。

这个习惯的养成最初只是因为记性不好，后来慢慢变成一种自律训练——每天固定时间做同一件事，哪怕只做10分钟，也比想起来才做要有效得多。正如娄老师所说，能力来自“可重复的小循环 + 可观察的反馈”，这件事让我相信持续投入的力量。

底线承诺：本课程所有作业坚持独立思考，引用必标明来源，不伪造经历，不搬运他人思考冒充自己的。

二、现状、经验和计划

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

选择计算机专业，很大程度上是因为高中时期第一次写出能运行的程序时，那种“把想法变成现实”的感觉让我觉得有意思。后来逐渐意识到，计算机技术渗透到各行各业，这个方向的路足够宽。

但距离一名合格的IT专业毕业生，我清楚自己还有明显差距。以下是从技能调查表中选出的7项我认为特别重要的技能：

技能 目前水平(0-9) 目标水平(0-9) 提高手段
数据结构与算法 3 6 ①每周3题刻意练习；②按“题意→状态→转移→复杂度”复盘错题
编程语言与工程规范 4 6 ①每两周重构一个小项目；②统一命名、格式化、静态检查
Git/GitHub协作 2 6 ①用Git Flow管理课程作业；②练习分支、PR、冲突处理
测试与调试 2 5 ①学习单元测试；②给旧代码补回归测试；③用覆盖率找盲区
需求分析与软件设计 2 5 ①研读《构建之法》；②写代码前先写“目标-角色-场景-验收标准”
技术文档写作 3 6 ①坚持写技术博客；②给自己项目写规范README
团队协作与沟通 3 6 ①积极参与结对和团队项目；②主动承担不同角色

水平说明：5表示能通过面试，9表示世界一流。

（2）阅读博客心得

a) 为什么认真上课？

网上的免费教学视频和教程很多，但自学的问题在于知识碎片化，缺少完整的知识体系，更难体验到真实的团队开发流程。课堂上能搭建系统性的知识框架，结对编程和团队项目是自学很难复制的实战机会。同时，课堂讨论和博客交流能让我看到别人的思路，发现自己认知的盲区。所以我选择认真参与这门课程。

b) 师生关系与困难应对

我在大学中体验过的师生关系，多数是“老师讲、学生听”的传统模式。但我希望这门课更像是健身教练与学员的关系——教练提供科学的训练方法和反馈，学员自己流汗出力，最终效果取决于学员的执行力。

如果作业难度超出我的能力，我会选择 C：向老师和同学请教，花更多时间，把作业全部完成。遇到难题先自己查资料尝试，解决不了就主动讨论，而不是直接放弃或索要及格分。

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

在软件开发中，参考别人的代码和思路是正常且高效的学习方式。关键区别在于：

  • 合理引用：借鉴他人资料，清晰标注来源，在别人成果基础上做独立的修改、拓展和创新
  • 抄袭：直接复制粘贴他人的文字或代码，不标注出处，当作自己的产出
  • 剽窃：盗用他人成果，稍作修改后隐瞒原始来源，冒充原创

本课程中，我承诺所有引用（包括代码片段、思路、文字）均明确标注来源，作业坚持独立完成。

（3）未来方向选择与规划

几年后，我倾向于毕业后直接从事软件开发工作。相比考研或考公，这个选择的好处是能更早积累实际工程经验，在真实项目中快速成长。

优势：有坚持做记录和复盘的习惯，遇到问题愿意反复调试；愿意主动接触新技术。

劣势：缺乏大型项目实战经验，工程思维薄弱，代码积累量不足，对完整软件开发生命周期不熟悉。

本学期规划：

  • 认真完成软件工程全部作业（博客随笔、个人项目、结对项目、团队项目）
  • 读完《构建之法》，做好阅读笔记，输出思考问题
  • 用Git管理所有课程代码，养成版本控制习惯
  • 每周复盘学习内容，坚持写博客记录

（4）课程计划与代码量

当前代码量：C/C++约5000行，Python约7000行，Java约3000行，合计约15000行（精确到百行）。

关于代码量的思考：要入职一流软件公司，除了代码量（通常需要数万行以上积累），更重要的是代码质量和工程能力——包括测试、设计、协作等。从事高校教学科研则需要更深的理论功底和论文阅读量，而非单纯追求行数。

时间投入：我选择 D：比以前课要多很多，直到达到目标为止。除上课时间外，计划每周额外投入5-8小时用于课程学习。

本课程代码量目标：希望课程结束时累计新增2000-3000行，主要来自个人项目、结对项目和团队项目。

WOOP计划

Wish（愿望）：在本课程结束时，能够独立完成一个完整的软件项目，理解从需求分析到部署上线的全过程。

Outcome（结果）：如果能实现这个目标，我就能有底气把项目写在简历上，面试时能有实际案例可讲；更重要的是，不再恐惧“全流程开发”这件事。

Obstacles（障碍）：

  • 容易在遇到技术难题时陷入无限查资料模式，而不是动手先写一个能跑的版本
  • 时间管理不够精细，容易被其他事情分散注意力
  • 对未知技术有畏惧心理，不敢尝试没学过的东西

最可能的失败因素：不能长期自律，遇到困难容易放弃。之前很多flag都倒在这一步。

Plan（计划）：

  • 如果遇到技术难题查资料超过30分钟还没进展，那么我就先写一个最简单的能跑版本（哪怕很丑），再逐步完善
  • 如果想刷手机或干别的拖延，那么我就站起来离开电脑，走一圈回来继续写
  • 如果遇到没学过的技术不敢碰，那么我就先完成一个最小可运行示例，先跑通再理解

三、提有质量的问题——《构建之法》阅读思考

快速阅读《构建之法》后，结合其他同学提出的问题，我整理了以下5个问题：

问题一：关于“创新的时机”——“够好”和“完美”的度在哪？

章节：第16章“IT行业的创新”，关于“创新的时机”部分。

书中提到创新要把握时机，既要避免“分析麻痹”（想清楚所有细节再动手），也要避免“过早发布导致用户流失”。主张“足够好的软件”就可以发布。

我的困惑：但“足够好”的判断标准是什么？不同场景差异巨大——一个游戏卡顿用户可能还能接受，一个支付软件卡顿用户可能直接卸载。有没有可操作的判断方法，在“尽早发布”和“保证基础体验”之间找到平衡？还是说这只能靠经验直觉？

问题二：创新必须解决“痛点”吗？

章节：第16章，关于“创新的迷思”。

书中提到创新要“解决用户的痛苦”。但据我观察，有些创新产品出现前用户并没有明显的“痛苦”——短视频出现前，用户没有“每天刷15秒视频”的需求；微信红包出现前，用户没有“需要电子红包”的需求。这些产品创造的是新可能性，而非解决旧痛苦。

我的困惑：寻找创新方向时，应该紧盯用户已有的“痛苦”，还是更多关注技术突破带来的“新可能性”？这两种思路在实际中如何取舍？

问题三：个人或小团队在今天还能做出颠覆性创新吗？

章节：第16章“创新和作坊”。

书中对“作坊式创新”持谨慎态度，强调团队和流程的重要性。但今天AI工具（Copilot、ChatGPT）让一个人能完成以前小团队的开发工作，开源生态和云服务也大幅降低了验证想法的成本。

我的困惑：也许“作坊式创新”在今天不仅没过时，反而因为门槛降低更可行了？至少从“验证想法”这个阶段，个人开发者可能比大团队更高效？

问题四：用户体验与需求分析的区别是什么？

章节：第12章“用户体验”。

书中说很多成功的软件赢在用户体验，用5W1H方法判断用户体验。而需求分析通过用户调研获取需求。

我的困惑：用户体验和需求分析在实际操作中界限在哪里？为什么二者要作为独立的两个步骤？如果一个产品用户体验做得很好，是否意味着需求分析也做对了？

问题五：团队合作真的能到达“默契”阶段吗？

章节：第4-6章，关于团队和流程。

书中把两人合作比作跳舞，提出从矛盾到默契的阶段。但我观察多数课程项目的结对编程只是暂时组合，几乎不可能达到真正的默契。

我的困惑：对于课程中的短期团队，也许更现实的预期不是追求“默契”，而是建立清晰的规则和分工？在这种情况下，怎样才能让合作效率最大化？

四、前车之鉴——阅读前人博客的感想

感想一：写博客是“开源学习日志”

阅读了K-D-R-T同学的第一周作业随笔，文中提到“把学习过程搬到可检索、可复盘的公共空间”，这个说法让我很受触动。之前我觉得写博客主要是给别人看的，但换个角度想，它首先是对自己学习过程的记录——半年后翻回来看，能清楚看到自己当时在哪卡住了、后来怎么解决的。

文中还提到B类任务（重要不紧迫）容易被忽略，比如写博客、练项目、读技术书，这些事不会带来即时压力，但长期会拉开差距。我意识到自己过去也经常优先处理紧急但不重要的A类事情，而把B类一拖再拖。这学期我打算每周固定时间做B类事情，不等到“火烧眉毛”才动手。

感想二：关于“闪光点”的启发

在IntZhx2同学的博客中，他提到自己的闪光点是“长期拼乐高培养的耐心和细节把控力”，这个角度让我重新思考“闪光点”的定义——它不一定要是拿过奖的技能，任何一件你能长期坚持做、并且从中获得成长的事情，都可以成为你的优势。

我发现自己之前写“闪光点”时总觉得没什么可写，是因为把标准定得太高了。其实能坚持三年写日记、能在电脑前连续调试几小时不放弃，这些本身就值得被看见。

感想三：关于“足够好”和“完美”

在Ajie8021同学对《构建之法》第16章的提问中，他提出了“‘够好’和‘完美’之间的度到底在哪”这个问题。我读到这里产生了共鸣——我自己经常因为想“做到最好”而迟迟不动手，结果拖到最后匆忙完成，质量反而更差。

这位同学的观点给了我启发：也许“完成”本身比“完美”更重要。先写一个能跑的版本，再逐步改进，比一开始就追求完美要高效得多。这个思路我打算应用到本学期的各项作业中。

参考资料：

posted @ 2026-09-06 22:58  mwq111  阅读(4)  评论(0)    收藏  举报