软件工程第一周作业

第一周作业

这个作业属于哪个课程	软件工程
这个作业要求在哪里	第一周作业
这个作业的目标	熟悉博客园与GitHub的使用，撰写个人技术博客，回顾自身现状并制定本学期学习计划。

---

1. 介绍自己，建博客

说到闪光点，似乎想不到有什么。我的爱好有很多，写作、音乐、历史等等，什么都喜欢玩一点，但属实算不上擅长。任何技能的习得都需要耐得住寂寞的重复练习，就算不能学有所成，过程中得到的快乐也是人生体验，所以我会勇于尝试新事物。

写博客也是同样的道理，刚开始可能觉得麻烦，但坚持记录自己的思考和成长，回头看一定会感谢现在的自己。

2. 现状、经验和计划

（1）专业选择与职业技能

我选择计算机专业，主要是为了以后找工作容易一点，要说多喜欢倒也算不上。

参考技能调查表，我认为对我特别重要的几项技能及提升计划如下：

技能项	① 目前水平 (0-9)	② 目标水平 (0-9)	③ 提高手段
编程语言	4	7	1. 在GitHub上阅读优秀开源项目源码； 2. 遇到Bug先独立调试再提问。
数据结构与算法	3	7	1. 整理自己的常见算法模板库； 2. 将算法思维应用到日常编码中。
软件测调能力	2	6	1. 学习编写单元测试（JUnit/pytest）； 2. 刻意练习使用Debug工具追踪变量； 3. 尝试写简单的测试用例覆盖边界条件。
团队协作	5	8	1. 阅读团队协作类文章并实践； 2. 写技术文档或博客梳理知识。
需求分析	2	5	1. 尝试从用户角度思考功能设计； 2. 分析一个小型开源软件的架构。

（2）阅读与思考心得

a) 为何要认真上课
因为大学课堂不仅是知识的传授，更是训练自学能力、思辨能力和纪律性的地方。如果只是在宿舍看视频，不仅缺少了与老师同学的思维碰撞，也缺少了强制性的输出来检验学习效果。我来上课，是为了逼自己走出舒适区。

b) 师生关系与面对困难的作业
在大学中，我体验过师生漠不关心的课堂氛围，也体验过老师单向输出的关系。
我希望这门课能做到老师根据学生能力布置任务并给反馈，我们努力完成并超越自己。
如果作业对我来说有些困难，我的选择是 C：向老师和同学请教，花更多时间，把作业全部完成。
因为只有啃下硬骨头，水平才能真的提升。如果是团队作业，我还会主动协调分工，保证整个团队不掉队。

c) 引用与抄袭的区别
在工作中，我们站在巨人的肩膀上，引用文献或开源代码是常态。但抄袭是指直接复制粘贴别人的成果，不注明出处，并当作自己的原创提交。
引用/借鉴和抄袭的分界线在于是否理解并内化了内容，是否注明来源，以及是否加上了自己的思考和改进。

（3）未来选择与今天的准备

大概是直接就业，也可能考公，对未来暂时没有明确的规划。对于就业，我的工程实战经验不多，不熟悉业务逻辑和团队流程，对于理论基础也不扎实，在底层原理上钻研不深。如果想进入互联网行业，需要提高自己的代码能力和系统设计能力，不断学习进步。
针对本学期的准备，我计划：

1. 跟上课堂知识的学习，提高软件开发能力；
2. 增加项目经验，尝试独立做项目。

（4）本课程计划

代码量情况：
我目前的代码量：C语言2000行，Java 5000行，主要是课程作业和个人实践。
为进入一流的软件公司，我估计至少需要几万行以上的高质量代码积累。
从事高校教学科研工作，则更看重论文和算法推演，代码量要求不同，但逻辑严密度更高。

时间投入：
我打算平均每周拿出8 ~ 9小时用在这门课上。
我的选择是C：比以前的课稍多一点
我计划本课程结束时，完成3000 ~ 5000行的代码量，平均每周300~500行。

WOOP 计划：
Wish：在本学期结束时，能够独立开发一个具有完整前端+后端+数据库的Web应用，并部署到云服务器上，且代码通过单元测试。
Outcome：当实现这个愿望时，我可以把项目链接写在简历上，面试时自信地演示；我会因为掌握了全栈开发的流程而非常有成就感，不再畏惧空白项目。
Obstacles：容易分心，写着写着就想刷手机看视频，静不下心；其他课程作业多，时间碎片化，容易中断编程思路。
Plan：
If 写着代码想拿起手机刷短视频，then 我立刻把手机放到宿舍床上，去走廊走两圈再回来。
If 其他课程作业挤占了大量时间，then 我采用番茄工作法，利用早起和晚上的大块时间专注编程，每天至少保证2小时沉浸式写代码。
If 遇到难解的Bug想放弃，then 我强制自己先用纸笔画出逻辑流程图，再逐步打印中间变量定位问题，坚持1小时后再请教他人。

3. 提有质量的问题

快速通读了《构建之法》，以下是我暂时不太理解或想深入探讨的5个问题：

问题一：软件开发的工作量和质量是矛盾的吗？
在实际敏捷开发中，经常面临着这个迭代必须上线的压力。此时，如果为了赶上截止日期而牺牲代码质量，这和书中所倡导的工程师应该始终追求高质量是否冲突？
我理解团队希望又快又好，但当不得不取舍时，有没有一个公认的可接受的底线标准？比如在创业公司，是先活下去还是先完美？

问题二：敏捷是否具有“领域局限性”？
文中介绍了“瀑布模型”和“敏捷流程”，并明显推崇敏捷。
但我查资料看到，很多大型军工、航天项目依然使用瀑布模型或V模型。
如果我们未来的工作是开发一个银行核心交易系统或自动驾驶系统，是否就不能盲目追求敏捷的快速迭代，而必须严格遵循文档和层层审批？如果是这样，那么这门课大力推广敏捷的意义在哪里，是不是为了培养我们小步快跑的思维习惯？

问题三：作为一个缺乏行业经验的学生，如何高效地判断用户反馈的优先级？
书中强调“用户说的需求不一定是真实需求”，要挖掘“痛点”。
我的经验是：在做小组项目时，我们直接发问卷问同学“你想要什么功能”，结果收回来的答案五花八门且都很表面。
没有一种比较科学的方法论，能在有限的时间和预算内，准确地过滤掉伪需求？

问题四：纸面典型用户一定更好吗？
书中用“典型用户（Persona）”来帮助团队聚焦。
我反对完全依赖纸面上的“典型用户”进行设计。原因是我觉得开发者很容易陷入“我认为用户会这么用”的陷阱，纸上人物写得再详细，也不如让真实的试用者操作一遍。
在无法接触大量真实用户的学生项目中，我们是否应该放弃写复杂的Persona文档，直接把精力花在做一个简陋原型去给人测试上？

问题五：作为学生，如何在“完成作业拿学分”和“尝试创新思维”之间取得平衡？
书中提到“创新的迷思”，提到很多伟大的创新最初并不被看好。
我查了资料，发现软件行业确实有很多先发优势变成先发劣势的例子。
我的困惑是：书中鼓励我们敢于创新，但作业评分往往有明确的功能要求和测试覆盖率指标。在这种评价体系下，我们尝试“非常规”的解题思路或架构，很有可能会因为风险高而拿不到高分。

4. 前车之鉴

阅读了前辈们的经验教训，针对其中两篇写下我的具体感想：

感想一：关于时间管理 —— 《把每天把要做的事情分成ABCD四类》

文章链接：A. 每天要做的事情分成ABCD四类
我以前经常陷入“假忙碌”，每天泡在图书馆却感觉什么都没做成。看完这篇关于ABCD分类法的文章，我反思自己往往是在用C类（紧迫不重要）的事情来逃避B类（重要不紧迫）的长远学习，比如先把这个格式调好再看算法。
我决定从现在开始，每周日用一张A4纸画好四象限，把下周的计划填入，优先保证B类事项每天至少有2小时的完整时间，而不是被各种临时的C类消息打乱节奏。

感想二：关于科班迷茫 —— 《你是否也觉得自己是科班，但没学懂计算机？》

文章链接：B. 你是否也觉得自己是科班，但没学懂计算机？
这篇文章简直写出了我的心声，我确实经常有“学完一本书，只会做课后题，不知道有什么用”的感觉。看到前辈说“计算机不是看会的，是练会的”，我感到很惭愧。以前我总是纠结于看懂每一个数学推导，却很少动手去把代码跑起来。不管懂不懂，先把代码敲一遍跑起来，遇到报错再回头翻书。这也是我在这门课中要重点攻克的事情，不要怕动手，先做了再说。

---

附：GitHub 仓库

我已新建了与 ID 同名的仓库，并在 README 中进行了自我介绍。
我的 GitHub 地址是：https://github.com/Deanna8080/Deanna8080

附：博客园 Markdown 编辑器设置截图