第一周作业

这个作业属于哪个课程：https://edu.cnblogs.com/campus/gdgy/Class56-Grade2024-CS
这个作业的要求：https://edu.cnblogs.com/campus/gdgy/Class56-Grade2024-CS/homework/15692
这个作业的目标：完成自我介绍、现状分析与学期规划、阅读《构建之法》并提出有质量的问题、阅读前人经验并撰写感想。
Github账号：https://github.com/mosquito512
博客园账号：https://www.cnblogs.com/kai4051
一、介绍自己
基本信息：
大三，计算机科学与技术专业。平时写写代码、折腾点小东西，不算大佬，但确实喜欢干这行。
说说我的闪光点
让我说自己的优点，我想了半天，觉得最拿得出手的就是——我能把想法变成真的。很多人都有过”哎我觉得可以做一个 XXX”的时候，但大部分人想完就算了。我不太一样，我会真的去做。课余时间我在小红书上发了几个自己写的小工具，不知不觉积累到了大概 6000 个用户。说 6000 好像挺唬人的，其实就是几个小工具而已，跟那些大项目没法比。但这个过程我自己觉得挺有收获的——没人布置任务、没有deadline、没人催我，纯粹就是自己想到了，然后就做了。从想清楚要做什么，到写代码，到发了之后看用户反馈哪里不好用，再到改，来来回回折腾了好几个月。还有一点，我做事比较靠谱。说做就做，不会拖到最后一天才开始赶。这个优点听起来很普通，但实际你会发现，光是这一点就已经比很多人强了。组队做项目的时候，队友最怕的就是那种”说好了但就是不动”的人，我至少不会是那个人。
写博客这事
说写博客花时间，确实。但我觉得有用。以后找工作，简历上写”精通 Python”，面试官每天看几百份简历都这么写。但如果你能甩出一个博客链接，里面有自己写的技术总结、踩坑记录，那就不一样了。博客算是技术人的一个门面，你不一定要做得多华丽，但至少能证明你真的在学、在想。而且有个事我体会很深：当你试图把一个东西写清楚给别人看的时候，你会发现自己其实还有很多地方没搞懂。写博客某种意义上是在逼自己把知识吃透，而不只是”大概知道”。所以我会尽量坚持写。写得好不好另说，先写起来。
二、现状、经验和计划
（1）选了这行，还差多少？
为什么学计算机说实话，高考填志愿的时候没想太多。就是对电脑感兴趣，觉得这行工作机会多，就选了。进来之后才发现，“感兴趣”和”能干好”中间差了不少东西。
不过现在也不后悔，学了三年了，虽然很多东西还没学到位，但至少方向是确定的。
技能差距——选了 6 项我觉得最该补的：

技能	目前水平（0-9）	课程结束想达到（0-9）	怎么提升
Python 实战能力	4	6	每周写 2 个小项目练手；读开源项目代码；找同学互相 review
数据结构与算法	4	6	每天刷 LeetCode 保持手感；系统过一遍教材；参加组队练习或比赛
软件工程/项目管理	1	4	认真跟这门课的项目流程走；读《构建之法》；在团队里试一下敏捷开发那套
Git/GitHub	2	5	以后所有项目都强制用 Git 管理；搞懂分支合并的工作流；试着给开源项目提 PR
团队协作	2	5	课程团队项目好好做；学会写让别人能看懂的文档和注释；主动承担沟通协调的角色
测试	1	4	学单元测试怎么写；在项目里试着用 TDD；了解一些自动化测试的工具
最大的短板很明显——工程能力和协作经验。之前做的东西基本都是自己一个人搞定的，怎么跟别人一起写代码、怎么管理一个正经的软件项目，这些我基本是空白。这也是我想从这门课里学到的最核心的东西。
（2）阅读心得
a) 我为什么来上课
不绕弯子：大学里确实有那种"去了也没啥用"的课，大家心里都有数。但这门课不太一样。它不是让你坐着听一学期然后期末考个试就完了。要做项目、要写代码、要跟别人合作、要写文档——这些就是我以后上班天天要做的事。说白了，这门课可能是大学里离真实工作最近的一门了。看了那个学生的思考，有个点挺触动我的：你来上课不是为了给老师面子，是为了自己。我都大三了，再过一年多就要找工作了，如果现在还在混，到面试的时候混不下去的还是我自己。
b) 师生关系和面对困难
大学这几年体验过几种师生关系。最多的是"老师在上面讲、学生在下面干自己的"，也有少数老师会跟学生互动多一些，但整体来说，大学里的师生关系比高中淡了很多。这门课我希望能更像教练和运动员的关系——教练负责定计划、指出问题、推着你往前走；运动员负责认真练、主动反馈、不断改进。不是老师说什么就做什么的服从关系，也不是各管各的松散关系。作业太难怎么办？我选 C——问人、多花时间、全做完。道理很简单：如果作业对你来说毫无难度，那你在这门课里基本学不到东西。难才是正常的。问老师和同学也不丢人，真正丢人的是明明不会还装作会，或者直接抄一份交上去。
c) 参考和抄袭，界限在哪
这个其实不难分清。参考是你看了别人的方案，理解了思路，然后自己写，并且标注清楚"这部分思路来源于 XXX"。抄袭是你直接拿别人的东西，换个名字就说是自己的。做开发的人天天都在用别人的东西——开源库、框架、Stack Overflow 上的代码。这不算抄袭，因为你知道这些工具是谁做的，你也没说那是你自己写的。这门课我会注意几点：用了别人的代码就写上来源和链接；团队项目里分清谁写了哪部分；开源代码注意许可证。
学校对抄袭的处分挺重的，轻的作业零分，重的课直接挂。没必要为了省几个小时去赌这个。
（3）以后的打算
毕业直接就业。不考研的原因我也想过——对我来说，早一年进公司积累实战经验，比在学校多待两三年更有效率。做开发这个岗位，经验很多时候比学历值钱。当然这不是说学历不重要，只是对我个人来说，直接工作的性价比更高。跟其他同学比：
优势方面，我有自己独立做过产品、发出去让人用的经历。这个经验让我比纯刷题的同学多了一点"产品感"——不只是代码能不能跑，还要想用户用着顺不顺。执行力也算一个，我不是那种需要别人盯着才干活的人。
劣势也有。团队协作经验几乎为零，之前做的东西全是自己一个人干的，一旦涉及到多人配合，我基本得从头学。还有就是算法底子不算特别扎实，跟竞赛选手比差距明显。
这学期的打算：
围绕"就业"这个目标，我想在这学期做到几件事：一是通过课程项目把软件开发的完整流程走一遍，需求、设计、开发、测试、部署，别落下哪个环节；二是好好练团队协作，学会怎么跟别人一起写代码；三是把课程项目做好，到时候面试能拿出来说。
（4）课程计划
对这门课的期待
看了一些国内外软件工程课的教学方式，我希望这门课能做到几点：项目别太假，最好有一定真实复杂度；要有团队合作，别一个人从头做到尾；要有迭代，不是交一次就完事；重视工程规范，文档、Git、测试这些别糊弄过去。
我自己是打算把每次作业当成真正在做项目来对待的，不是那种"写完了赶紧交"的态度。
代码量
语言 目前大概写了多少
Python ~3000 行
C/C++ ~2000 行
JS/前端相关 ~1000 行
合计 ~6000 行
听说要进一流互联网公司，有效代码量起码得到 2-3 万行（不算复制粘贴的那种）。差距还很大，这学期得使劲赶。
时间投入
每周打算花 10-12 小时在这门课上，含上课时间。
前两年有没有浪费时间？
多少有一点。但现在说这个没意义，重要的是接下来怎么做。
我选 D——比以前的课多很多，直到达到目标。这不是空话，后面会用 WOOP 来细化怎么落实。
计划这学期新增代码量大概 5000 行，平均每周 300-400 行。
WOOP
Wish（我想干嘛）：
跟团队完整地做一个正经的软件项目，从需求分析开始到最终上线交付，走完全流程。让自己的工程能力和协作能力有一个质的提升，而不是停留在"一个人写小工具"的阶段。
Outcome（如果成了会怎样）：
学期结束的时候，我能拿出一个完整的项目，面试的时候能自信地讲清楚这个项目的设计思路、技术选型、团队协作过程。这比简历上干巴巴地写"熟悉 XXX"强太多了。到那时候我会觉得，这学期的时间没白花。
Obstacle（什么会挡我）：
内部问题：我有时候会在某个细节上死磕，明明可以先做一个能用的版本，但就是忍不住想把它做到完美，结果拖慢了整体进度。还有就是遇到难题的时候会有点烦躁，想刷会儿手机缓缓，然后一刷就停不下来了。
外部问题：大三了，其他课的作业和考试也会扎堆来，某些周可能压力会很大。
最可能让我失败的原因：
学期开始大家都挺有干劲的，我也不例外。但到学期中间，项目难度上来了、新鲜感过去了、其他课的压力也来了，我可能会开始降低标准——“差不多就行了”“能交就行”。一旦开始这么想，后面就一路滑坡了。
Plan（具体怎么应对）：

如果我发现自己在一个细节上纠结超过半小时还没结果，那就先做一个能用的版本，标记 TODO，继续推进后面的工作。完美主义可以有，但不能以牺牲进度为代价。
如果我写代码写到一半开始想刷手机，我就先把手机扔到另一个房间（或者锁进抽屉），然后设一个 25 分钟倒计时，告诉自己"先写完这个番茄钟再说"。通常写完一个番茄钟之后，就进入状态了。
如果某周其他课的任务特别多，我周日晚上会列一个优先级清单，把这门课的时间先固定下来，不让别的事情挤掉。
三、提有质量的问题
读《构建之法》后的 5 个问题
问题 1：敏捷开发是不是万能的？
第 6 章 敏捷开发
书里把敏捷开发讲得很好，Scrum、Sprint、每日站会，感觉这套东西用上就能解决大部分问题。
但我有个疑问：那些对安全性要求特别高的项目怎么办？比如飞机的控制系统、医院的设备、银行的核心交易系统。这些地方出个 bug 可能就是要命的事，频繁迭代真的合适吗？
我查了一下，确实有"混合模式"的说法，就是关键部分用严格的流程管，不关键的部分用敏捷。但书里基本没怎么讨论敏捷的局限性，给人一种"敏捷就是答案"的感觉。
我想知道的是： 在实际工作中，怎么判断一个项目该不该用敏捷？有没有"不该敏捷"的情况？
问题 2：用户自己都说不清楚想要什么，怎么办？
第 8 章 需求管理
书里说"用户说的需求往往不是真正的需求"，这个我深有体会。
我做小红书工具的时候，有用户跟我说"能不能加个导出功能"。聊了几句才发现，他其实就是想把结果发给朋友看看，最终我加了一个分享按钮，他反而觉得比导出好用多了。
但问题来了：不是每次都有机会跟用户聊这么细的。而且有些时候，用户自己也确实想不明白要什么，等你做出来了才知道不是自己要的。
我的困惑： 书上讲的什么用户调研、用户画像，理论上没毛病，但实际做起来很难做准确。有没有什么更接地气的方法，能帮我们在资源有限的情况下（比如就是一个学生团队项目），尽量搞清楚用户到底要什么？
问题 3：小团队怎么做代码复审才不流于形式？
第 9 章 代码复审
Code Review 的重要性不用多说，道理大家都懂。但现实是——在学生团队里，每个人都在赶自己的进度，很少有人愿意花时间认真看别人的代码。到最后要么随便扫一眼说"LGTM"，要么干脆跳过。
我看了些资料，大厂一般有强制的 Review 流程，不 review 不能合并。但学生团队没这个约束，全靠自觉，就很难推行。
我想问： 在没有什么强制手段的小团队里，怎么让 Code Review 真正做起来？有没有什么轻量级的做法，不至于太花时间但又有效果？
问题 4：自己测自己的代码，怎么避免盲区？
第 13 章 软件测试
这个问题我特别想聊。自己做东西的时候，测试全靠自觉。但我发现一个很明显的问题：我测试的时候，总是不自觉地按照"正确的使用方式"去操作，因为我自己写的代码，我知道该怎么用才不会出错。
结果就是，用户一用就崩的地方，我自己测十遍都测不出来
学生团队通常也没有专门的测试人员，大家都是开发兼测试。
我的困惑： 在这种情况下，有什么办法能跳出"开发者视角"？交叉测试（你来测我的，我来测你的）有用吗？还是说有别的更实用的方法？
问题 5：创新能被"管"出来吗？
第 16 章 创新
书里讲了不少关于创新的内容，包括怎么营造有利于创新的环境、Google 的 20% 自由时间之类的。
但我总觉得这个事有点被高估了。我自己的经验是：我做小红书那几个工具，没有谁让我做、没有什么"创新时间"的安排，就是某天突然想到了，然后就去做了。反而有时候我刻意想"我得想一个创新的点子"，什么都想不出来。Google 的 20% 时间后来好像也基本名存实亡了。这让我怀疑，所谓的"创新管理"到底是真的有用，还是只是一种美好的愿景？
我的疑问： 创新到底能不能被管理手段促进？还是说，管理能做的只是"别妨碍创新"，至于创新本身，得靠个人？
关于反馈
选 C。
不想当那种一学期到头一句话不说的人。有问题就问，对自己好，对教学也好。以后工作了也是一样的，闷头干活不吭声的人，发展通常不会太好。
四、前车之鉴
感想 1：时间分类这件事
文章 A：https://book.douban.com/subject/4006425/discussion/22803733/
把每天要做的事分成 ABCD 四类
这个 ABCD 分类法我其实以前就见过，但一直没真正用起来。看完这篇文章之后又想了一下，发现我确实有个毛病："重要但不紧急"的事总是被搁置。
比如一直说要好好学 Git、写技术博客、系统性地补一补计算机网络的知识——这些事我知道很重要，但它们不紧急，所以就一直拖着。拖到什么时候呢？拖到它们变成"又重要又紧急"的时候，比如面试前突击。
这学期我想试试每周日晚上花十分钟，简单规划一下下周的事情。不需要多复杂，就是提醒自己别忘了那些"重要但不紧急"的事。

感想 2：自学这条路
文章 D：https://www.cnblogs.com/xiaozhi_5638/p/4485805.html
偏科生自学摸索的道路
这篇让我挺有感触的。作者是自己摸索出来的，很多东西课堂上不会教，只能自己去找资源、踩坑、慢慢搞。
我虽然不算偏科，但做小红书工具那段时间确实是纯靠自学的。课堂教的东西和实际做项目需要的东西之间有一个挺大的gap，这个gap只能自己想办法填。过程挺痛苦的，经常一个问题卡半天，但回头看，那段时间进步反而是最快的。
文章里还提到了实习经验对应届生的重要性。这点我也认同，计划大三下或大四找个实习，去真实的工作环境里看看自己还差多少。

感想 3：技术栈和职业路线
文章 I：https://www.cnblogs.com/unruledboy/p/DevCareer.html
大佬的技术栈与成长之路
看完大佬的成长路径，有个想法让我放松了不少：技术栈这个东西不是一成不变的，重要的是学习能力，而不是你现在会什么。
我之前会焦虑，觉得自己要学的东西太多了，Python、Java、Go、各种框架、数据库、云服务……好像永远学不完。但看了这篇文章，我意识到大佬也不是什么都会的，他们在不同阶段学不同的东西，关键是基础扎实、学得快。
所以与其焦虑"我还没学 XXX"，不如把数据结构、算法、软件工程这些基础课先啃下来。框架会变，基础不会。

写在最后
写这篇博客花了不短的时间，但确实让我把自己的情况理清楚了不少。平时忙着赶各种 deadline，很少有机会停下来想想自己到底在什么位置、要往哪走。计划写完了，接下来就看执行了。希望期末回头看这篇文章的时候，不用觉得丢人。