北航软工第一次作业
软工博客一
项目 | 内容 |
---|---|
这个作业属于哪个课程 | 2020春季计算机学院软件工程(罗杰 任健) |
这个作业的要求在哪里 | 第一次个人作业 |
我在这个课程的目标 | 不求变强,只求做好,成为一颗有用的螺丝钉。 |
这个作业在哪个具体方面帮助我实现目标 | 读通教材、理解团队配合和个人发展 |
参考资料 | 链接地址1 |
一、快速看完整部教材,列出你仍然不懂的5到10个问题
问题一、
像软工一样无聊的课程很多,比如航概,思修,毛概。尤其是政治课程,无法提高我们的专业水平,我们应该以怎样的态度面对这些课程?
在邹老师的《构建之法》讲义中提到了很多学生表示“软件工程”是一门非常无聊的课程,在课堂上大部分学生选择睡觉或者写自己的代码。其实早在大一下,在很多课程上已经可以看出这样的迹象,即便是当时很重要的数据结构——有过竞赛经历的不屑于听,预习过的没必要听,没预习过的打算课后自学......各种各样的态度都有。
这次疫情将软件工程变成了网络授课某种意义上是一种改进,从本质上迎合了大部分6系学生偏爱自学的需求。在平时的学习过程中,大部分知识其实不是从课本中习得的,而是从博客和各类论坛中获得的,原因就是方便、快捷、精准。而软件工程的网络课可以让我们更自由的学习。
问题在于有些课即便换成网络授课,依然改变不了它乏味的本质。我个人以为,软件工程要比法律课要有意思的多。比如知识产权法的网络课,或者法律、科技与社会。这些课程所教授的内容,对开发者而言大有裨益,但是大量记忆背诵就像是噩梦一样萦绕在心头。还有工科数学分析,我们承认它的难度比数学分析要低一档,但是至今我们仍没有需要用到高等数学以上数学分析以下的知识,当初的那些苦涩的推理却又吓跑了一堆人。
大学是相对自由的,没有了父母和班主任的管辖,我们也不再逼着自己啃这些看着就乏味的课程。就软工而言,邹老师是如何把软工讲得有趣的呢?B站上有位up主是来自中国政法大学的教授罗翔,靠刑法学成为了百万粉丝的网红,软工又是否可以战胜刑法学?
问题二、
20%的(测试)工作耗费80%的时间,既然测试工作占到开发80%的时间,那么把测试工作评估成20%的工作量是不是太少了?
根据经验,3个小时写完的代码,如果存在潜在漏洞,可能要花3~6个小时去发现,甚至作业AC漏洞都没有暴露。测试工作是99分到100分的最后一步,也是决胜一步,在1/N评分制里就是100和50的差距。
在结对项目里,假设一个人开发,一个人测试(虽然书中不建议这么做)。一甲2小时写完走人,乙8个小时哼哧哼哧将代码完善到至臻完美,最后甲拿走了80%的功劳显然不合适。那么在一个团队当中,测试人员的工作量该如何定义?
其实测试人员的工作量是不好明确定义的,因为从时间上来评定工作一是可以虚报,二是时间不等于效率。很可能乙8小时一个漏洞都没找出来。
那么从“找出漏洞数”结合“最后成绩”分配功劳合适吗?
也不合适,因为甲的开发工作越好,乙的工作评定就会走向两个极端——满分的测试工作或零分的测试工作——找出为数不多的bug或者唯数不多的bug没找出来。
好在敏捷流程中没有明确表明到底何人,何时,以何种优先级来完成这20%的任务,开发人员有时候也要担任测试人员,只要把测试工作均匀分配,就不存在测试工作到底占比多少的问题。
问题三、
文中提到一个细节,公司通过发放毛绒玩具提高了程序员的劳动生产力。那么毛绒玩具对学生也有用吗?
很多大厂在内部采访的时候都会有这样的画面,比如腾讯,办公桌上有各式的企鹅公仔,我一度以为这是他们在作秀,变相宣传公司文化,但是书中确实提到这一点,毛绒玩具可以提高员工的生产力。还有b站,他们的员工办公桌上则是各式各样的手办。
我见过部分同学在自己的电脑旁边放一只小黄鸭,网上也流传着小黄鸭能debug的传说。我曾经对这种行为很困惑,也问过一些同学这么做是否有效果。他们的回答是:其实是一种心理暗示,当你工作遇到瓶颈时,可以对着它讲解自己的思路,放松大脑,从而有利于找出问题。
于是有一天我也买了一个手办放在电脑旁边,但是当我遇到bug的时候非常焦虑,根本不会记得毛绒公仔或者小黄鸭,满脑子都是代码里的逻辑。可能毛绒玩具只对部分学生有用吧?
问题四、
在团队换人过程中遇到熟人社会该怎么办?例如:甲乙丙丁四人,丁的工作量最少,但丁和甲乙同一宿舍。最后投票的结果是丙出局,这是否对丙不太公平?
直至目前,凡是有配合的工作,都会有大腿和咸鱼。大腿一般会承担50%的工作,而剩下的人则是给大佬打打杂,浑水摸鱼。而大佬在这样一个团队中有绝对话语权,比如NBA的勒布朗·詹姆斯甚至可以操纵球员交易。当第三位的工作其实不比第四位出众很多的时候,熟人社会很可能让第三位扫地走人,而把和第一位有特殊关系(不排除情侣)的人留下。
我在挑选队伍的时候就非常注重这一点,坚决不去有小团体(宿舍关系、游戏好友关系、情侣关系)的团队,生怕自己被排斥。
问题五、
在Page237页有这样一个急功近利的青年叫作小飞,他迫切渴望成为白领,这也是每个刚毕业大学生的真实想法。阿超的建议是一步步在历练中实现,并以打球为例暗示他能力还有所欠缺。大学生到底在那些方面不能直接胜任管理层?这些方面可以在大学磨练吗?
这些问题可能要涉及到职场经验。我看过一个知乎问答,上面提到了工作中的学生思维,让同事非常反感。刚毕业的我们多多少少会有一点学生思维,并且感觉不出自己的问题。还有工作中的人情冷暖,也在我们的处理能力之外。一些在特定环境中才会有的话术,经验,可能在工作后就会自然习得,但在大学就只能看个似懂非懂。
为人处世的道理看了很多,看着都懂,做到的却没几个。在大学迫切的想为工作做准备是好的,但是能做到多少还要看条件限制。
问题六、
一个团队中有开发人员、测试人员、项目经理等,每个同学扮演一个角色,于是对这方面的工作有了一定的了解,但是相较来说,其他人就缺失了这方面的经验。有什么好的办法让每个人都能知道PM该干什么?其他人该干什么?
对于以后的工作,很难说以后就和现在的分工一样。今天我担任的PM,以后我可能只是一个开发人员;或者我今天是一个测试,以后要担任PM却还是个萌新。经验缺失是一个严重的损伤。
可以肯定,在团队合作中会有交流、交流就有经验分享,也就知道队友做了什么,但即便有经验交流,也不可能吸纳所有。在其位谋其政,任其职尽其责。每个人最知晓的应该还是自己的本职工作,也对队友工作充满好奇。
可以让每个同学隔一段时间发一篇工作报告,专门详述自己做了什么,出于什么需求要这么做,这么做了有什么效果,走过什么弯路,哪些方法都是可行的,最后出于什么原因决定这么做。有需求的人自然会去看,但代价是加重了每个人的工作量。
二、请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人?
“software”:1958年,Tukey的论文”The Teaching of Concrete Mathematics”中首次使用software的概念。
1953年Richard R.Carhart在备忘录中使用software一词
“software engineering”:1968年在第一个软件工程大会上,NATO首次提出software engineering的概念。
三、【附加题】:大家知道了软件和软件工程的起源,请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事?(+2')
千年虫事件:在上个世纪,软件业者从来没想过他们的代码和产品会跨入新千年。
就像我们现在写的万年历一样,例如2020/03/05,如果我的代码使用到9999/12/31,就可能重演千年虫事件。
四、上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些, 各有什么优缺点?
用户(估计)
Name | Users | Projects |
---|---|---|
GitHub | 31,000,000 | 100,000,000 |
Bitbucket | 5,000,000 | Unknown |
Launchpad | 3,965,288 | 40,881 |
SourceForge | 3,700,000 | 500,000 |
GitLab | 100,000 | 546,000 |
GNU Savannah | 93,346 | 3,848 |
OSDN | 54,826 | 6,294 |
Ourproject.org | 6,353 | 1,846 |
-- 数据来源《维基百科》
优缺点
Microsoft TFS
优点:任务版本上能将需求、项目进度一览无余,对于小团队来说比甘特图更有用;集成了项目管理、版本控制、bug跟踪,能有效实现SCRUM;能与VS无缝接合。
缺点:功能太复杂,不够直观;访问、填写记录不方便;需要64位操作系统。
Github
优点:比svn更快的分支切换;随时提交代码;有全世界最大的开源社区
缺点:由于是分布式,如果忘记push就会导致不同步;windows下使用命令行不太方便。
Apple XCode:
优点:可以自动创建分类视图;自动提供撤销、重做和保存功能
缺点:更新版本可能导致插件失效
Mercurial
优点:更轻松的管理。 更健壮的系统。对网络的依赖性更低。
缺点:跨平台性能较差,容易出现编码问题;分支管理不灵活。
Bugzilla
优点:免费,支持汉化
缺点:只能管理缺陷
Trac
优点:Trac做一个SCM配置管理平台,意味着它有良好的扩大性;Trac的权限体系是比拟齐备的设计;十分灵敏,可以为所欲为的定制,可以和TortoiseSVN集成。
缺陷:不支持多项目,
五、调查完目前流行的源程序版本管理软件和项目管理软件后,请你选择其中至少2个软件来进行动手实践
从大二开始,我们第一个接触到的就是Git,经常在Gitlab和Github上上传自己的代码,对Git的使用也有一定的经验。使用Git管理可以有效的控制版本,防止误删导致的版本丢失,还有版本回退功能,方便找回过往的版本。而Mercurial则接触的比较少,网上的资源也相对较少,可以看出是一款比较小众的版本管理软件,已经逐渐被人淡忘。