第一周作业：随笔

第一周作业：在实践中学会把代码做好

作业信息

项目 内容
这个作业属于哪个课程 计科24级6班
这个作业要求在哪里 第一周作业
这个作业的目标 建立博客和 GitHub 仓库，练习 Markdown、Git 和软件工程的基本方法，并通过阅读和实践形成自己的学习计划。

账号准备

博客园的默认编辑器已经改为 Markdown。

image

GitHub 仓库根目录已经添加 README，仓库地址如下：

image

GitHub 地址：https://github.com/FLC-niko

一、介绍自己，建立博客

我叫 吴与同，是广东工业大学计算机学院计科 24 级 6 班的学生。

我选择计算机科学与技术专业，是因为我对计算机如何解决问题比较感兴趣。以前我对编程的理解比较简单，觉得只要把代码写出来、运行成功就可以了。学习之后才发现，一个程序能运行只是第一步，代码是否容易看懂、出了问题能不能找到原因、以后修改会不会影响其他功能，同样很重要。

我目前比较感兴趣的方向是 [个人信息：例如后端、人工智能、移动开发等]。现在还没有必要马上给自己定死一个方向，先把基础知识和动手能力打好更实际。

我的一个个人亮点是：[个人信息：写一件自己长期坚持的事情或比较擅长的事情，2—3 句即可]。这件事让我体会到，能力不是靠临时抱佛脚得到的，而是靠一段时间的练习和复盘慢慢积累起来的。

我建立博客，是想把学习过程留下来。以后遇到问题，我会尽量写清楚问题是怎么出现的、试过哪些办法、最后为什么这样解决，而不是只写一句“问题已解决”。这样的记录以后回头看，应该会比单纯保存一个代码文件更有用。

二、现状、经验和计划

1. 专业选择和目前的差距

我选择这个专业，最初有兴趣和就业考虑，也希望以后能做出真正被别人使用的软件。现在看来，成为一个合格的 IT 专业毕业生，不能只会几门语言，还要能把一个问题拆开，选择合适的方法，写出可以维护的代码，并且能和别人一起完成任务。

我目前的差距主要有以下几点：

  1. 基础知识还不够系统，数据结构、操作系统、计算机网络和数据库之间的联系还需要继续理解。
  2. 写代码时有时只关注结果，测试边界和异常情况的习惯还没有完全形成。
  3. Git 和 GitHub 用得不够熟，提交记录、分支和代码复审还需要在实际项目中练习。
  4. 遇到报错时容易直接搜索答案，应该先自己复现和定位问题，再参考资料。
  5. 技术表达能力还需要提高，要学会把一个模糊的问题说清楚。

2. 技能自评

评分采用 0 到 9 分，5 分表示基本能够通过相关面试，9 分表示世界一流水平。下面的分数是我按目前阶段做的一个暂时自评。

技能 目前水平 课程结束目标 具体做法
编程基础和代码规范 4 6 每周写小练习，注意命名、函数长度、重复代码和异常处理。
数据结构与算法 3 5 每周做 2 道题，写下思路和复杂度，不能只记答案。
调试与测试 3 6 给程序准备正常、边界和错误输入，保留典型报错及解决过程。
Git 与 GitHub 2 6 练习小步提交、分支、README、Issue 和基本的代码复审。
需求分析与软件设计 3 5 写代码前先写清楚用户、输入、输出和验收标准。
技术写作与沟通 4 6 每周记录一个真实问题，提问时说明背景、尝试和错误信息。

3. 为什么要来上课并认真参与

我阅读了《你为何要来上课并且认真参与》。我觉得上课不是为了等老师划重点，也不是人在教室里就算完成了学习。真正重要的是自己有没有跟着思考，有没有把听到的东西变成自己的理解。

以前遇到不会的内容，我有时会先放着，想着以后再补，结果往往就真的没有以后了。认真参与并不只是增加学习时间，而是上课时带着问题，课后动手验证，再根据结果修改自己的理解。以后我准备每次课前简单看一下材料，记下不懂的地方；课后至少用一个小例子验证当天学到的内容。

我也认同文章里关于注意力的提醒。一个小时如果一直在网页之间切换，看起来很忙，实际上没有完成什么。学习时应该先确定这一段时间要解决的具体问题。

4. 我希望形成的师生关系

我希望这门课的师生关系更像教练和学习者。老师负责给出方向、要求和反馈，学生负责主动练习、提出问题并承担结果。老师不只是给答案，学生也不能只等着老师把每一步都讲出来。

如果作业比较难，我选择 C：向老师和同学请教，花更多时间，把作业完成。我的做法是先自己拆任务，查课程资料和官方文档，做一个最小版本。如果仍然解决不了，就把复现步骤、报错信息和自己的猜测整理好，再去请教。这样得到的帮助才真正能变成自己的东西。

5. 引用、借鉴和抄袭

写程序和做研究时，参考别人的资料是很正常的。官方文档、教材、论文和开源项目都可以帮助我们少走弯路，但参考不等于把别人的成果改几个变量名就交上去。

我理解的区别是：

  • 引用要说明来源，最好写出作者、文章或项目名称和链接。
  • 借鉴要先理解原理，再根据自己的需求重新设计和实现，并说明自己改了什么。
  • 抄袭或剽窃是隐瞒来源，直接使用别人的文字、代码或思路，并把它说成自己的成果。

对于开源代码，还要看清楚许可证是否允许使用和修改。对于课程作业，则要遵守老师关于独立完成和讨论范围的要求。我的底线是：先独立尝试，参考资料必须注明来源，提交前能够解释自己提交的每一部分。学校关于抄袭的具体处理，以学校和学院公布的现行规定为准，我不会随意编造处罚条款。

6. 对未来的初步打算

目前我更倾向于软件开发和工程实践方向。几年后，我希望能参与一个真实项目，经历需求、设计、编码、测试、发布和维护，而不是只完成一次性的课堂题目。

我觉得自己的优势是愿意动手，也愿意在遇到问题时继续查资料；不足是基础还不够扎实，有时会拖延，遇到复杂任务容易一开始就觉得无从下手。接下来要做的不是给自己贴标签，而是把问题变成具体行动：

  1. 跟上课程进度，每次作业按时完成。
  2. 选一个小项目持续迭代，留下代码、测试和版本记录。
  3. 每周记录一个真正遇到的问题。
  4. 把数据结构、网络、数据库等基础知识和小项目结合起来学习。
  5. 学期末根据自己的代码仓库和博客记录，重新判断自己更适合哪个方向。

7. 这门课的计划

我期待这门课能让我知道软件是怎样从一个想法变成可以交付和维护的项目。我不想只记住“敏捷”“测试”“需求分析”这些名词，而是想知道它们在什么时候有用，做得不好会有什么问题。

我打算这样学习：

  • 课前花一点时间了解本周内容，带着问题上课；
  • 作业先做出最小可运行版本，再逐步增加功能；
  • 每次提交前进行一次测试和一次代码检查；
  • 遇到报错先复现，再搜索和提问；
  • 每次作业结束后写一个简短复盘；
  • 在 GitHub 和博客中记录可以公开的学习过程，不公开密码、密钥等隐私信息。

目前我暂时不考虑申请助教。等自己的基础、表达和代码复审能力更稳定之后，如果还有机会，我愿意再尝试帮助其他同学。

8. 代码量和时间安排

语言 当前代码量
Kotlin 41,000 行
Java 2,800 行
JavaScript/JSX 1,800 行
HTML 600 行
Shell/Batch 700 行
合计（源代码） 46,900 行

这次统计得到的未四舍五入源代码总量是 46,937 行，按题目要求精确到 100 行。XML、JSON、Gradle、Markdown 等文件主要属于资源、配置或文档，没有放进上面的源代码合计中。这个数字表示仓库中实际维护的源代码规模，不等于全部都是我从零写下的代码；尤其是项目中引用或合并的开源模块，应该在 README 和许可证中注明来源。

代码量可以说明练习规模，但不是能力的唯一标准。公司招聘不会只看一个人写了多少行代码，更看重基础知识、项目质量、解决问题的能力、测试意识和团队协作能力。高校教学科研也一样，代码只是成果的一部分，还要看研究问题、实验过程和表达能力。

我计划平均每周投入这门课 8 个小时，包括上课时间。本题的选择是 C：比以前的课稍多一些。如果后面发现这个时间不够，我会优先保证核心作业，再减少无计划刷网页和反复切换任务的时间。

本课程结束时，我计划完成大约 3000 行有明确用途、能运行或能复查的代码，平均每周完成约 200 行。这里不为了凑数字重复写无意义的代码，而是尽量让代码伴随说明、测试和提交记录。

9. WOOP 计划

Wish：愿望

我希望在课程结束时，能独立完成一个中小型软件实践，熟悉 GitHub 和 Markdown，养成测试、复盘和写技术记录的习惯。

Outcome：结果

如果做到这些，我以后面对陌生项目时，至少知道应该先理解需求、拆分任务、做出最小版本，然后通过测试和反馈逐步改进。我的 GitHub 仓库和博客也能清楚地展示自己是怎样完成一个项目的。

Obstacles：障碍

最大的障碍可能是拖延和任务安排不合理。任务刚开始时，如果觉得内容太多，我可能会先做一些简单但不重要的事情，结果真正需要思考的部分反而被拖到最后。

Plan：如果……那么……

  • 如果我连续 30 分钟没有推进，就把问题缩小，先完成一个最小步骤。
  • 如果程序报错，就先记录报错信息、复现步骤和最近的改动，再去搜索。
  • 如果我总想把项目一次做得很完整，就先完成能运行的版本，再逐步加功能。
  • 如果学习时想刷网页，就先完成一个 40 分钟的专注时段。
  • 如果某周事情太多，就先完成课程核心任务，周末再补充整理和拓展内容。

三、提有质量的问题，给认真的反馈

我快速阅读《构建之法（第三版）》后，整理了下面五个问题。每个问题都写了对应章节、我的理解和困惑。

问题一：能运行的程序就是好的软件吗？

出处：第 1 章“概论”，第 1.1 节“软件 = 程序 + 软件工程”。

我以前判断程序好不好，第一反应是看它能不能运行。但读到这一节后，我觉得能运行只是最低要求。一个程序还要考虑别人能不能看懂，出了问题能不能修，需求变化后能不能继续改。

我的问题是：如果只是自己使用的小脚本，没有团队，也不会长期维护，是不是就不需要软件工程？我的想法是，小脚本确实不必使用很复杂的流程，但至少应该写清楚使用方法，保留一个能运行的版本，并处理几个明显的错误情况。工程化不一定意味着增加很多形式，而是根据项目的风险决定做到什么程度。

问题二：单元测试怎样处理网络和数据库？

出处：第 2 章“个人技术和流程”，第 2.1 节“单元测试”。

单元测试的好处是快，而且每次运行结果应该比较稳定。但现在很多程序都要访问网络、数据库或文件。如果测试全部依赖真实环境，网络一波动就可能失败；如果全部用模拟数据，又可能没有发现真实接口的问题。

我认为应该把测试分层：单元测试主要验证自己的业务逻辑，网络和数据库通过接口隔离；集成测试再验证程序和真实依赖能不能配合；最后用少量端到端测试检查最重要的使用流程。这样不会把所有问题都压在一种测试上。以后写代码时，我也要尽量把业务逻辑和输入输出分开，避免一个函数什么都做。

问题三：什么时候该停止分析，先做出一个版本？

出处：第 3 章“软件工程师的成长”中关于“思维误区”的部分。

我做题或做项目时有过这样的情况：总觉得还没有完全想清楚，想先把所有资料看完再开始，最后花了很多时间准备，却没有真正写出东西。这和书中提到的分析麻痹比较像。

我的问题是，怎样区分认真分析和拖延？我现在给自己的标准是：只要目标、输入输出和验收方法已经比较清楚，剩下的问题可以通过小实验验证，就先做一个最小版本。做出来以后，很多原本想象中的问题会变得具体，反而更容易解决。当然，涉及安全、数据格式和公共接口的决定还是要多想一会儿，不能什么都靠试错。

问题四：敏捷迭代会不会变成只顾眼前、不做设计？

出处：第 6 章“敏捷流程”中关于短周期迭代和计划调整的内容。

我以前觉得敏捷就是“先写了再说”，但如果完全不设计，代码很快会变得混乱。另一方面，需求还没有确定时就设计一个很复杂的架构，也可能白费功夫。

我觉得比较实际的做法是，先把当前迭代真正需要的部分设计清楚，做出一个小版本，再根据反馈调整。数据格式、公共接口和安全相关的决定需要谨慎；局部实现则可以先用简单方案验证。每次迭代还应该留一点时间处理技术债，不能总说“以后再改”。

问题五：创新是有新想法，还是把想法验证出来？

出处：第 16 章“创新”中关于创新过程和需求验证的内容。

我以前容易把“想到了一个别人没做过的功能”当成创新。现在觉得，一个想法有没有价值，还要看它是不是解决了真实问题，用户愿不愿意用，以及能不能通过实践验证。

我的问题是，学生没有很多用户资源时，怎样判断自己不是只觉得这个想法有趣？我认为可以先找几个真实使用场景，问清楚别人现在是怎么解决的，再做一个很小的原型。先验证最关键的假设，不要一开始就花大量时间做完整系统。如果没有人愿意使用，就应该重新审视问题，而不是只继续堆功能。

认真反馈

这门课如果只在学期末收一次意见，很多问题可能已经来不及改了。我会尽量在遇到具体问题时及时反馈，例如作业要求哪里不清楚、某个工具是否难以使用、哪个环节花费的时间明显超出预期。反馈时我会说明事实和自己的建议，不只写“太难了”或“没问题”。

如果按选项选择，我倾向于 D：经常提问题，平时就给老师和助教反馈。提问不应该是为了证明课程有问题，而是为了让自己和老师都更早发现问题。

四、前车之鉴

1. 先做重要的事情

参考：把每天要做的事情分成 A、B、C、D 四类。

这篇文章给我的提醒很简单：忙不等于有效率。平时我也会把一些容易完成的事情放在前面，因为这样很快就有“完成了很多”的感觉，但真正重要的任务反而一直没动。

以后我会把事情按“重要”和“紧急”分开。课程作业和临近截止的任务属于必须先做的事情；基础补充和项目迭代虽然不急，也要提前固定时间。每天不列太长的清单，只先确定一件最重要的事，完成后再安排其他事情。

2. 速成培训和大学基础

参考：速成的培训班和打基础的大学教育有区别么。

培训班通常能让人较快学会某个工具，大学课程则更重视基础和迁移能力。两种学习方式解决的问题不同，不能简单地说哪一种完全没用。

这让我想到，框架和工具会更新，但数据结构、网络、数据库和操作系统中的一些基本思想不会因为工具变化就失效。如果只跟着教程敲代码，换一个环境可能就不会了。但基础也不能只背概念，还是要用小程序和实验把它们用起来。以后我会尽量把理论学习和项目练习放在一起。

3. 软件工程应该在实践中学习

参考：世界一流大学怎么教软件工程。

我比较认同文章中强调实践的部分。软件工程不是背几个流程名词，而是要在需求变化、多人协作、测试和发布中真正遇到问题，才会知道这些方法为什么有用。

以前我把作业看成“写完并提交就结束”，很少回头看。以后我想把作业当成一个小型项目，至少留下 README、提交记录、测试结果和复盘。这样即使项目规模不大，也能提前练习以后工作中会用到的习惯。

参考资料

posted @ 2026-09-02 16:50  FLC_Niko  阅读(6)  评论(0)    收藏  举报