软件工程第一周作业
| 这个作业属于哪个课程 | https://edu.cnblogs.com/campus/gdgy/Class56-Grade2024-CS/ |
|---|---|
| 这个作业要求在哪里 | https://edu.cnblogs.com/campus/gdgy/Class56-Grade2024-CS/homework/15692 |
| 这个作业的目标 | 写一篇博客随笔 |
1.自我介绍
大家好,我是一名专业为计算科学与技术的IT大三学生,学校位于广州。我的性格偏外向,熟了以后话会变多,平时比较照顾身边人的感受。我觉得自己身上一个闪光点是情绪比较稳定,很少因为遇到变故或者矛盾而情绪爆发,身边人都说我是个老好人,打游戏大多是听着队友在鸟语花香地输出,我在旁边附和几句。我的兴趣爱好有很多,小学在课外兴趣班学习了三年足球,不过是断断续续的,平时最常做的是看小说,看小说时格外钟情看段评,看别人的评论能学到一些东西,了解别人对这本书的一些看法以及玩一些书友才知道的梗。
2.现状,经验和计划
(1)
我选择计算机专业起初是因为计算机技术渗透各行各业,选择这个专业未来拥有充足的选择和发展空间而且是热门专业。后续深入了解之后发现计算机学科极具逻辑性与创造性,是推动科技发展、行业革新的核心力量。
| 技能 | 目前水平 | 课后期望水平 |
|---|---|---|
| 程序理解 | 3 | 7 |
| 需求分析 | 3 | 8 |
| 效能分析与改进 | 2 | 8 |
| 架构设计,模块化设计,接口设计 | 2 | 6 |
| 自主学习的能力 | 5 | 9 |
| 处理大数据 | 1 | 8 |
提升手段:
- 多阅读开源项目源码,逐行梳理代码逻辑
- 参考成熟项目的需求说明书,学习规范的需求拆解逻辑,多复盘项目出现的问题
- 学习代码冗余优化循环优化、逻辑简化的方法
- 学习软件工程模块化、接口设计、分层架构基础理论
- 制定阶段性自主学习计划,明确每周技术学习目标并严格落实
- 寻找公开大数据数据集开展实战练习,独立完成完整数据处理流程
(2)心得
如今有些人心态浮躁,人云亦云,丧失了自己的独自思考和判断力,我觉得不能用一句"这是水课,上了也没用"来作为自己不认真上课的理由。我心目中的老师和学生的关系是健身教练/健身学员的关系,老师教给学生一个系统有效的训练方法,我们学生就像刚健身的学员,眼界和阅历有限,没有能力随意评判课程好坏、定义知识无用。我们要做的是上课认真听讲,锻炼名为专注力的肌肉,以学员的心态踏实跟从老师的节奏,学习系统的专业方法,认真对待每一堂课、每一次训练。坚持长期积累和练习,不断提升专注力和自身能力,为未来学习和职场发展积蓄足够的竞争力。
如果老师布置的作业对你来说有些困难,我会选择向老师和同学请教,花更多时间,把作业全部完成。作业设置本身就是训练我们工程能力的过程,首先自己独立思考,查阅资料解决问题,遇到实在无法解决的难题,主动向老师、同学请教解题思路,投入更多的时间,尽力完整完成全部作业。
我们学习和生活中经常要引用文献、参考他人资料,在别人的工作基础上继续开发,合理借鉴和抄袭剽窃有着本质区别。合理的参考借鉴,是吸收前人的思路和方法,读懂理解之后,加入自己独立的思考、改造与创新,产出属于自己的成果,要明确标注来源,说明哪些内容来自他人,哪些是自己的产出。而抄袭剽窃,是直接照搬他人文档和观点,不标注来源,把别人的劳动成果伪装成自己的作品来提交。学术诚信是我们的底线,要养成诚实守信做项目的习惯,尊重他人的劳动成果,做一名合格的软件从业者。
(3)首先要立足本专业,夯实计算机核心硬实力,认真上好每一堂专业课,提高代码能力,学会运用AI,紧跟时代。然后要拓展自身综合能力,给自己保留更多选择空间。在学习之余,我会多去了解不同出路的真实状态,通过课程项目、志愿实践等不同经历,看清自己擅长什么、向往什么,不把自己局限在单一可能性里。现阶段的核心就是抓住大学宝贵的时光,打磨专业本领、塑造踏实严谨的习惯和认真学习的状态
(4)这门课程的学习计划我期待通过这门软件工程课程建立完整工程化开发思维,掌握程序理解、需求分析、架构模块化设计、性能调优、项目协作、代码质量把控等实战能力,学会用工程视角看待软件项目。上课阶段我会紧跟老师讲课节奏,认真听讲梳理思路,不随意走神,课后及时复盘课堂知识点。认真完成课程作业与项目任务,借鉴优秀项目的开发思路。积极对待课程实践环节,在项目中锻炼各项软件技能。不想当助教。
目前代码量是3000行想要入职一流互联网、人工智能软件公司,需要积累几万行级别有效项目代码,如果走高校教学科研路线,除代码实践外,还需要大量阅读论文、做实验,代码量要求略低于工业界,但也要数万行高质量实验代码。课程结束计划完成新增代码量:5000 行
3.提有质量的问题, 给认真的反馈
问题一:“足够好的软件” 评判标准是否缺少学生课程项目场景的适配?
出处:第 1 章 概论,1.3 软件工程的目标:在约束条件下创造 “足够好” 的软件
我看了这一段文字:软件工程的目标不是打造完美软件,而是在约束条件下,做出 “足够好” 的软件,从用户满意度、可靠性、可维护性等维度来衡量软件质量。
我有这个问题:书中 “足够好” 的标准更多面向商业市场下的正式软件产品。但是我们大学生课程小组项目,资源、时间、人员技术能力都非常有限,没有真实付费用户。那学生作业项目,该如何定义什么叫 “足够好”?是否还直接套用这套评价标准?
我的困惑是:商业软件的 “足够好”,是受市场、资金、用户约束;学生项目约束主要是课程截止时间、组员编程水平。两套约束条件完全不一样,书中这套 “足够好” 评价维度,哪些要保留,哪些要做取舍?学生项目的 “足够好”,有没有一套简化可落地的评判标尺?
问题二:敏捷流程强调快速迭代,学生团队很容易变成 “只堆功能,忽视质量”,书中给出的解法在校园项目中为什么很难落地?
出处:第 6 章 敏捷流程,6.2 敏捷流程的问题和解法
我看了这一段文字:敏捷流程会遇到的问题:团队仓促交付、技术债务累积;对应的解法是重视单元测试、代码复审、及时重构,在迭代中兼顾质量。
我有这个问题:敏捷开发提倡小步快跑,频繁迭代。但学生课程项目时间紧,很多组员优先完成看得见的功能,单元测试、代码复审经常被直接跳过,技术债务不断堆积。书中给出的解决手段,为什么在很多学生小组实践中很难真正执行?
我的困惑是:书中给出的解决方案,是建立在团队成员都具备自觉工程素养的前提下。但学生本身工程经验不足,课程压力大。如果团队成员主观上不愿意投入测试、复审,敏捷流程本身有没有强制的机制约束?还是说敏捷完全依赖团队成员的自觉?如果只能靠自觉,那对于新手学生团队,敏捷是不是天然就容易变质为粗糙的快速堆功能?
问题三:典型用户、典型场景做需求分析,会不会陷入 “样本偏差”,漏掉真实的边缘用户?
出处:第 10 章 用户体验设计,10.1 典型场景和典型用户
我看了这一段文字:我们要提炼典型用户,描述典型用户的场景,从典型用户出发挖掘软件的需求,聚焦主要人群,放弃次要的边缘用户。
我有这个问题:过度依赖典型用户做需求分析,会不会带来样本偏差?把大部分精力放在 “理想化典型用户”,而忽略真实世界的边缘使用者,造成软件对部分真实用户完全不可用?
我查了资料,很多产品案例显示,部分产品真实的高频使用者,并不是前期设想的典型用户。根据我的实践,做课程项目做需求调研的时候,我们会找身边熟悉的同学作为典型用户,很容易只收集和我们想法接近的人的意见。
我的困惑是:书中强调要聚焦典型用户,适当放弃边缘需求。但是作为学生,我们很难大规模调研海量用户,只能接触少量典型样本。那我们如何平衡 “聚焦典型用户” 和 “避免样本偏见”?有没有简单可操作手段,防止我们被少数几个典型用户的想法带偏,做出脱离现实的需求?
问题四:创新迷思中说 “创新不一定是从0到1,改良也是重要创新”,学生课程项目该怎么区分改良创新和简单照搬别人的项目?
出处:第 16 章 IT 行业的创新,16.1 创新的迷思
我看了这一段文字:创新就是从0到1。事实:很多成功的创新是从1到N,把已有的技术、模式复用改造到新场景,同样属于重要创新,执行细节比原始点子更重要。
我有这个问题:既然改良、改造现有方案也算创新,那么在课程作业中,界限在哪里?怎么区分 “借鉴改造的改良创新” 和直接抄袭、照搬开源项目,避免把抄袭包装成 “改良式创新”?
我的困惑是:从1到N改良创新,和抄袭改造的分界线是什么?仅仅改界面、改少量参数算不算改良创新?学生项目中,什么样的改动幅度、新增多少自己的业务逻辑,才可以算作课程意义上的创新?除了标注来源之外,还有什么判断标准?
问题五:书中对 PM(项目经理)能力要求很高,但是学生 PM 大多没有管理经验,新手 PM 最优先要学会的到底是管理协调还是技术开发?
出处:第 9 章 项目经理,9.1 PM 是啥;第 5 章团队和流程,5.2 软件团队模式
我看了这一段文字:PM 做开发和测试之外的所有事情。PM 需要做需求分析、任务拆解、进度管控、团队沟通风险识别,不一定写大量代码。
我有这个问题:学生小组里面的 PM,大多是普通同学,没有项目管理实战经验。那作为学生 PM,应该优先把精力放在管理协调,还是也要深度参与编码开发?如果 PM 写太多代码,就会无暇顾及进度管理;如果完全不写代码,又看不懂组员代码,无法评估任务难度,这种两难该如何处理?
我的困惑是:针对学生这种新手 PM,有没有优先级排序?学生 PM 应当投入多少比例时间写代码,多少时间做管理?书中描述的 PM 角色是面向工业界成熟团队,针对校园课程小组,PM 角色是否需要做简化调整?
老师在教学过程中会要求学生填写对课程的反馈我会经常提问题,平时就经常给老师和助教提反馈。真正高效的学习,应当主动输出反馈。平时听课、做作业遇到理解不了的知识点、对课程安排有想法、实践出现和理论不符的现象,我会主动向老师、助教提出疑问与建议。不光按时认真完成课程反馈表单,也会在日常学习中及时表达自己的真实感受:哪些内容难以理解,哪些实践任务存在困难,哪些地方可以优化。
反馈不是给老师挑毛病,而是双向促进。一方面帮助老师收集教学信息,改进教学;另一方面,提问和反馈的过程,也是梳理自己思路、认清自身短板的过程,就像健身时主动告诉教练身体感受,教练才能及时调整训练计划,自己才能获得更好的成长。只有双向的沟通反馈,这套 “教练‑学员” 式的教学模式才能发挥最大价值。
4. 前车之鉴
感想一:《你是否也觉得自己是科班,但没学懂计算机?》
链接:https://book.douban.com/subject/4006425/discussion/22803961/
读完这篇讨论,我内心很有共鸣。很多计算机科班学生和文中描述一样:考试成绩不错,能拿到课程分数甚至奖学金,学完数据结构、操作系统、计算机网络一整套专业课,但是动手写项目的时候却手足无措,感觉自己 “科班但是没学懂计算机”。
就像书中刘帅的经历,上课机械听课、完成作业,把知识点当成考试记忆的内容,缺少把理论串联、动手实践的过程。课堂上学了算法,但很少完整从零实现;背熟网络协议,却不会去分析真实网络请求;看懂课本概念,却不知道这些知识在真实软件项目里怎么发挥作用。这就是 “看得懂、考得好,但是不会用”。
我反思自己现在的学习,也存在这个隐患。如果仅仅满足于作业及格、考试拿分,不去主动动手实践,不去打通各个课程之间知识的联系,就算修完所有学分,也算不上真正学懂计算机。科班的优势不是那张成绩单,而是一整套完整的专业课程体系。
对我而言,之后不能只被动接收课堂知识。上完课要多追问:这个知识点可以解决什么实际问题?尝试动手把课本上的算法、模型亲手实现出来,把书本理论落地到小项目。不能只停留在记住概念,要做到理解原理、可以实践,真正把科班的优势发挥出来,避免 “科班却没学懂计算机” 的困境。
感想二:《偏科生自学摸索的道路。实习经验对应届生重要吗?》
链接:https://www.cnblogs.com/xiaozhi_5638/p/4485805.html
这篇博客探讨两个现实问题:偏科学生如何自学成长,以及实习对于应届生到底有多重要。
很多在校学生不一定每一门科目都均衡优秀,存在偏科。有些同学理论课成绩一般,但是愿意花大量时间自学编程、做项目;也有同学卷面分数很高,却几乎没有实战经历。文章让我意识到,计算机行业并不要求每一门课程都考高分,但是自学能力是程序员的核心底色。遇到自己薄弱的地方,不能坐等课堂讲授,要主动查阅文档、跟着案例练习,靠自学补齐短板。
而关于实习,我之前会有两种极端想法:一种觉得没有大厂实习就完全找不到工作;另一种觉得学好课本知识就足够,实习可有可无。读完文章之后我的看法变得更加客观:实习最大价值不只是简历上的一段经历,而是让我们接触真实的软件开发流程,了解团队协作、版本管理、需求迭代这些课堂很少讲到的工程实践内容。 当然,如果暂时没有拿到实习机会,也不代表无路可走。可以通过课程大作业、个人开源项目,自己模拟完整项目流程,积累可以展示的实战成果,弥补实习经历的不足。
结合我现在的阶段,我计划一方面持续锻炼自学能力,补齐自己薄弱的技术点;另一方面重视实践,不管是课程项目还是以后寻找实习,都把目标放在积累真实解决问题的能力,而不是单纯追求一纸经历。
后台博文编辑界面的截图:

我的GitHub仓库是:https://github.com/zzh26s/zzh26s

浙公网安备 33010602011771号