项目 | 内容 |
---|---|
这个作业属于哪个课程 | 课程社区 |
这个作业的要求在哪里 | 作业要求 |
提问作业链接 | 开学的提问作业 |
我在这个课程的目标是 | 体验规范软件开发流程,积累团队合作经验,同时积累项目经验,提高自身竞争力 |
这个作业在哪个具体方面帮助我实现目标 | 回顾、总结、反思 |
尝试对自己曾经提出的问题进行解答
问题1:goto的使用
书中内容只要有助于程序逻辑的清晰体现,什么方法都可以使用,包括goto
根据小组作业软工开发的实际体验,确实是只要满足了敏捷和可扩展性的需求的方法就是好方法。
开发并不是数学证明题,并没有唯一的满分答案。过于纠结细节和完美主义会影响整体功能实现的进度。
问题2:如何避免由客观水平差距和主观意愿问题带来的结对编程退化为单人编程,如果这样结对编程还有什么意义
客观水平差距是合作形式没办法改变的,如果说经过了繁杂的结对程序结果最后代码的水平仍然取决于各方面水平高的那一位,那结对编程到底有什么意义呢?只剩下对较低水平的那一位的教育意义了吗?可是结对编程应该是一种软件工程的实操技术手段,最终目的是为了得到更高质量的代码。
主观意愿问题,比起人数更多的团队合作,结对两人中的任何一人都具有不可替代性,如果某一人出现问题那结对编程的过程也会立刻崩溃,变成单打独斗。
以上是开学我对结对编程提出的疑问。
说实话,第三周第四周单词链的结对编程过程反而让我更加质疑结对编程的有效性了。任务量过大、任务板块过多,在这种高压的情况下我没有体会到结对编程的任何好处,我仍然保留我的疑问。
我是在后期团队任务的线下集中开发过程中才体会到了结对编程的作用。两轮敏捷开发的任务总量更大,但是创造性没有那么强,可以分解成更多子任务,团队讨论和规划后总时间更充裕。在这种情况下任务的合理分解、一带一面对面编程,确实能让水平相对不足的成员快速进步,然后再反过来分担水平较强成员的负担。
问题3:软件工程中用户与开发团队的冲突,项目商业化的需求,如何协调与平衡
书中内容:项目是项目团队成员做的,但是项目的商业价值要用户说了算…”我觉得用户会喜欢“的东西可能和”用户觉得“是两回事所以要多沟通
(暴言)团队项目最后受欢迎与否,70%都源于产品的创意是否符合用户需求。比如本学期我所在小组的项目buaamapforum,专攻北航校内地点细节这个创意的产出只花了我们1%的时间,但是最后我个人觉得它对产品效果起了最大的推动效果。所以开发成员不要太钻牛角尖也许是一个很不错的选择。并且,哪怕是最简单的需求,也可以有很多细节去完善,感觉开学提问的时候有点太眼高手低了。
问题4:典型用户如何在真实应用场景中起作用
典型用户最后是为了应用到场景,那么能不能直接取消中间这个环节、变成设计者提出需求→根据需求实现功能?
并且,典型用户构造的起点就是设计者提出的功能,增加一个中间环节真的能覆盖设计者的设计盲点吗?
以上是开学我对典型用户提出的疑问。
帮团队项目构思场景测试的时候,我体会到了典型用户的作用。开发者脑海里顺功能的时候会根据功能实现的分区来构思,但是先立一个典型用户人设,再顺功能也就能自然而然地从用户的角度思考。
举例:我们地图(包含地图钉)和论坛的部分是分两阶段开发的,但是用户的正常逻辑为浏览地图-浏览地图钉-转向相关帖子,或者看集合贴-看地图构思路线,这两个部分是连起来的,有了典型用户人设之后思路就会很丝滑。
问题5:多种设备的用户体验提高
(正好团队项目做了移动端适配)移动端对日常功能友好太多,有些6系之外的同学甚至不会每天都跟电脑相依为命,拿起手机就能完成的事情为什么要打开电脑呢?
一个例子:团队alpha阶段在插入地图钉的时候还要专门跑一趟然后在电脑上上传图片,beta阶段做完移动端适配后路过某地就能直接拍照上传
是否原来的问题还不明白?是否产生了新的问题?如果有,请提出。
见上部分的第二个问题,结对编程)
在项目的需求/设计/实现/测试/发布/维护阶段(6个阶段)中都学到了什么“知识点”
-
需求:提需求之前一定要先评估该需求是否有价值(使用频率、必要性等等),提出针对特定人群的好需求已经成功了一大半
-
设计:
- 各部分的设计有一些前后依赖关系,应该首先对设计哪些部分设计的顺序有一个整体的设计
- 设计完了需要严格付诸文档,并且统一参照文档完成,避免带来不一致
- 设计也不可能百分百完美,如果坚持原先不合理设计的成本远高于了重新设计的沟通成本,那一定要果断重新设计,不要惧怕从头开始
-
实现:遵守流程;要对自己交付的代码负责;勤于与对接的人员沟通;注意代码规范
-
测试:除了自己部分的功能性测试,还要考虑压力测试,安全性测试等。
-
发布:
- 面向目标用户(我们的项目BUAA-MAP-FORUM完全面向北航学生)和同温层(e.g. 本学期都选修了软工的2006和已经三学期选修的2021)的社媒宣发,看起来手段很low,其实效果说不定是最好的
- 需要持续、见缝插针地宣传
-
维护:需要反馈通道并收集反馈信息,以及要对反馈的处理流程进行规定
结合自己在个人项目/结对编程/团队项目的经历,谈谈自己的理解或心得
技术收获:
本学期的软工课程最大的收获不是代码能力上的,而是完整的合作项目经验上的。不如说,这学期之前我对会写代码的认识还停留在很会刷算法题或者可以对编译课设机组课设这种单人项目做可扩展的迭代优化,现在对版本管理、协作开发、设计、CI/CD、测试、等都有了一些(粗浅的)认识。
关于git:结对的时候还完全不懂如何对一个git版本管理的项目进行协作开发,到团队项目结束之后已经养成了一些还算可以的规范(比如完全戒掉了直接push到重要分支的习惯,凡commit必有格式,每次合并前进行代码审查),强迫症更严重了
课程体验:
其实团队开发阶段并没有想象中的那么痛苦,每轮开发设计(分锅)之后也就是按部就班的实现,队友都很nice很负责,大学唯一一次体会到小组作业的正面作用!
感谢老师助教的付出,感谢队友们的体谅和帮助~