软工第一次博客作业
项目 | 内容 |
---|---|
本作业属于北航 2020 年春软件工程 | 博客园班级连接 |
本作业是本课程第一次个人作业 | 作业要求 |
我在这个课程的目标是 | 收获团队项目开发经验,提高自己的软件开发水平 |
这个作业在哪个具体方面帮助我实现目标 | 大致了解软件工程及常用的管理工具与服务 |
《构建之法》的阅读与疑惑
问题 1:在 2.3 节中,作者列出了大学四年级生与有经验的软件工程师的个人开发流程对比数据,其中可以注意到,软件工程师对于需求分析更为重视。对此,我有一些想法。
需求分析是连接用户和开发者的重要桥梁,但是用户和开发者对于需求的着重点可能会有区别。因此,是否需要一个中间层帮助用户和开发者更好地完成需求分析,换言之,将需求分析的任务从软件工程师中剥离出来,让中间层作为这一环节的主要负责人,软件工程师以协助的身份参与到需求分析中。
问题 2:在 4.5 节中,作者介绍了结对编程的含义及其有效性。但是考虑到结对编程会涉及到人与人之间的密切交流,我认为在选择结对伙伴时需要解决以下的一些问题。
首先,是两人的软件工程水平差距。如果两人的水平悬殊,一位是经验丰富的高手,另一位是初涉职场的新手,这种情况下的结对编程毫无疑问会演变成为高手的个人表演,新手的参与程度会比较低。而如果两人的水平相当,如何能够保证两双相似的眼睛的 review 结果能够优于单独编程,不致于浪费人力。
其次,是两人的性格差异。每一位开发者都有自己的偏好,无论是代码的品味、编辑器的设置等与编码相关的,还是待人处事等与人际交往相关的,都可能会产生冲突。如何避免与解决两位开发者之间的冲突,我认为这是一个难点。
问题 3:在 5.2 节中,作者介绍了软件团队的各种模式。结合实际情况,我认为不同模式之间是可以结合的。
以 Vim 项目为例子,它是由作者brammool完全掌控的,对于项目的走向有着绝对话语权,因此可以看成是“明星模式”。同时,有许多志愿者为 Vim 贡献自己的代码,可以视作是“社区模式”。那么,对于 Vim 项目而言,其团队模式是两种模式的结合。
问题 4:第 12 章与第 13 章分别讲述了用户体验和软件测试,在一个开发周期内,软件测试应是在用户体验之前进行。但是,现在似乎有着其他的测试方式,即让部分用户作为小白鼠的方式进行测试。
Windows 10 有 Windows Insider Program,参与到该 Program 的用户可以提前一个大版本体验到 Windows 10 的新内容。但是 Insider 版本是不稳定的,用户以稳定性为代价换取了新体验,同时向微软反馈使用体验与 bugs。显然,这种方式有效地削减了企业在测试方面的成本,但是用户测试难以覆盖到所有可能的代码执行路径,这导致了正式版本发布时仍可能存在着会影响用户体验的 bug。这种利用用户进行测试的策略是否合理?
问题 5:在 14.2 节中,作者讲解了独立测试人员的重要性。但是,我对此有一些疑问。
测试人员对于代码的熟悉程度远不及开发者,可能会以用户无法达到的方式来调用 API 进行测试,这些时候可能就会导致不存在的 bug 产生。这种情况下,是否需要让测试人员对代码的结构有一定的了解?
“软件”和“软件工程”词汇的出现
- “软件”最早在公开发表刊物中出现是在 John W. Tukey 在 American Mathematical Monthly 上的文章 The Teaching of Concrete Mathematics,时间是 1958 年 1 月 9 日。
- “软件工程”最早出现不可考,但公开使用始于 Margaret Hamilton 在阿波罗计划中提出。
目前流行的源程序版本管理软件和项目管理服务
- git
- 优点:分布式,本地可存储完整的版本库,可离线操作,功能强大而灵活
- 缺点:代码保密性差,上手难度大,命令设计随意而不一致,不适合管理二进制文件
- svn
- 优点:集中式,良好的权限机制,学习难度低,开发者无需消耗大量的存储空间以克隆完整的版本库
- 缺点:版本控制能力一般,需要在线工作
- Mercurial
- 优点:总体而言,是操作简单的 git
- 缺点:branch 管理能力弱,社区活跃度不及 git
- Azure DevOps
- 优点:功能完善且强大
- 缺点:无
- Bugzilla
- 优点:完善的权限机制,可定制化的工作流,本地化支持
- 缺点:管理内容单一