BUAA软件工程 第一次阅读作业
项目 | 内容 |
---|---|
这个作业属于哪个课程? | 北航软工 |
这个作业的要求在哪里? | 第一次个人作业 |
我在这个课程的目标是? | 学习高效严谨的软件工程开发过程,建立团队意识 |
这个作业在哪个具体方面帮助我实现目标 | 熟悉并了解软件工程的基本知识,建立兴趣 |
快速看完整部教材,列出你仍然不懂的5到10个问题
1.软件开发中的风险控制?
现代软件开发中难免要用到一些第三方开发的开源库,比如python,js等语言,这些库为我们的开发带来便利的同时,也为我们带来了安全隐患,因为这些库的质量是我们无法保证的。比如18年圣诞节发生的阿里的开源UI框架Ant Design中的彩蛋事件。那么,在成熟的商业公司的开发中,是怎样看待和使用这些第三方库的?
2.单元测试的随机性,复杂性,如何建立合适的断言
测试已经是软件开发中必不可少的一个步骤,我们确实是有必要对程序进行全面严谨的单元测试。但是以我们本次的结对开发任务为例,我们提供一个找到最长单词链的接口。测试的时候,难道我们就只测试返回的长度而不去考虑整个链的组成么?尤其是我们将测试集的单词量级定为10000时,如何构造一个合适的数据集?人工构造耗时耗力。
3.代码的命名规范
书中好像对代码的简洁性要求比较高,例如它给出这样的例子,”表示全年假日的列表“不用写arraylistOfHolidays
,可以直接写作holidays
,我感觉这个与我的开发经验是不符的,按照我的写法,应该会被命名为holidaysList
,这样可以看出变量的数据类型。
4.代码的验收测试
越长的代码越不可能没有bug,我们平时几百行的程序当然可以做到完成所有测试并改正找到的bug,像一些商业软件最后的验收会不会有妥协。是一定要做到测试中的零bug,还是对bug分类,不影响核心功能的bug如果工期紧或者代价大就不改了?
5.需求引导与变更
我之前用的一款手机APP突然从左右滑动翻页,换到了上下滑动自动加载。我不太习惯,用户社区里也有很多反对的声音。但是几个更新版本下来,APP并没有回滚的意思。我们在开发中遇到这种事应该怎么决定,比如处于技术或者美观的考虑需要改正用户的习惯操作时,我们应该怎么抉择?
请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人?
软件(英语:software):第一个关于软件的理论是艾伦图灵在1935年发表的论文《On Computable Numbers, with an Application to the Entscheidungsproblem》。但是软件software一词是在1953年,Richard R.Carhart在公司的备忘录中首次提出并使用这个词.
软件工程是1968年,NATO(北约)的科技委员会召集了近50名一流的编程人员、计算机科学家和工业界巨头,讨论和制定摆脱“软件危机”的对策。会议上提出了软件工程software engineer一词。根据后来的报导,应该是女科学家Margaret Hamilton在会议上提出了该词。
大家知道了软件和软件工程的起源,请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事?
我在知乎上看到过这样一个笑话,算是跟软件有关吧
当年麻省理工的一名系统管理员,忽然收到统计系主任打来的求助电话“咱们的邮件发不了500英里以外的地方,其实,是520英里更准确点”。
系统管理员心里¥!&……*&。
不过在他开始用自己的邮件测试后,发现邮件的确只能发往520英里以内,其余的收件地点一律失败。于是在他一片纠结中他渐渐开始发现问题,邮件服务器被人更新过操作系统(当年还是SunOS),但是由于操作系统的发行版往往配备了旧版软件,于是在更新操作系统的时候邮件软件反而被降级了(Sendmail 8 -> Sendmail 5)。
于是进一步调查发现,在更新操作系统时,管理员自己编写的Sendmail配置文件(sendmail.cf)被保留了下来。这样就出现了这种状况:Sendmail 5尝试解析Sendmail 8的配置文件。但是为什么会是500miles呢?为什么是500miles咧?
原因是这样的,Sendmail 5面对陌生的配置文件,凡是不理解的部分都会忽略,凡是没设置过的配置项自动设置成0。这样其中有一个被设置成0,这一项就是 (连接远端SMTP服务器的超时时间)timeout to connect to the remote SMTP server。后来经过实验,发现0秒的timeout会导致Sendmail在3毫秒后中断连接。
所以,为啥是500miles?
在当年,MIT的校园网是没有那么多router的,也就没那么多网络延迟,所以连接一个远端主机的时间大概就是光所需的时间。于是3毫秒, 就意味着:558英里。也就是558英里以外的服务器,都无法连接到,而558英里以内的服务器,都可以正常通信。
当当当,这就是500英里的bug啦。
上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些, 各有什么优缺点?请按照最近一两年使用人数的多少, 从多到少排序并说明各自有多少用户(估计),工具的优缺点(可以引用相关资料并注明来源)。
在*18年做的一次开发者调查中,有一定用户数量的版本管理软件有Git,Subversion,Team Foundation Version Control,Mercurial等等(除了单纯的复制,备份),他们具体的排名是这样的:
在全体开发者的范围内排名:
在专业开发这的范围内排名:
其实这些软件中,我实际用过的也只有git,所以只好结合它们各自的百科和博客纸上谈兵一番。
git
-
优点
适合分布式开发,强调个体。
公共服务器压力和数据量都不会太大。
速度快、灵活。
任意两个开发者之间可以很容易的解决冲突。
离线工作。
-
缺点
- 学习周期相对而言比较长。
- 不符合常规思维。
- 代码保密性差,一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。
Subversion(SVN)
-
优点
采用集中式,易于管理,保证安全性;
管理方便,逻辑明确,理念符合常规思维;
代码的一致性高;
适合人数不多的项目开发;
允许一个文件有任意多的可命名属性,会关注所有的文件类型;
支持二进制文件,更容易处理大文件;
支持空目录。
-
缺点
- 服务器压力太大,数据库容量暴增;
- 必须连接在服务器上,否则基本不能工作、提交、对比、还原等;
- 不适合开源开发
Team Foundation Version Control
- 优点
- 可视化做的很好
- 缺点
- 中文资料太少
- 需要借助微软的开发平台
Mercurial
- 优点
- 轻量,易用性强
- 缺点
- 中文博客和资料比较少