第一次阅读做业

时间 2019-12-12

标签第一次阅读繁體版

原文原文链接

软件工程第一次阅读做业

项目	内容
本次做业所属课程	2019BUAA软件工程
本次做业要求	第1次我的做业
我在本课程的目标	熟悉软件工程流程，了解团队开发
本次做业的帮助	帮助理解《构建之法》,更深刻了解课程大纲

1.快速看完整部教材，列出你仍然不懂的5到10个问题

问题1.1 第二章我的技术和流程

单元测试必须由最熟悉代码的人(程序的做者)来写。
单元测试应该覆盖全部的代码路径。c++

看到这两条，我发现OO课后期的要求也是这样的（在书上看到了不少去年OO的方法论），可是当时由于全部做业都是我的做业所以没有想过其中的道理，可是我对这个存在必定的疑问。我认为一个程序员在面对一个问题去思考解决方法的时候颇有可能会存在必定的考虑不全的问题，会有必定的思惟受限的问题。我以为让做者继续写单元测试的话做者不少针对问题的遗漏点还会继续发现不出来，因此我以为应该须要第二我的辅助进行单元测试来发现思路以及设计上的遗漏点。
另外有个问题，单元测试要求覆盖全部的代码路径，是须要在完成基本的代码调试以及性能优化以后进行仍是说从完成程序编码就进行？书的后文提到单元测试须要与代码一块儿维护，若是每次作修改都须要覆盖全部的代码路径带来的维护成本是否会过大？git

问题1.2 计算机专业考级真的有用吗

职业发展——考级之路程序员

在中国，软件工程师的职业资格考试有: 计算机等级考试和全国计算机技术与软件专业技术资格考试github

这个我有必定的疑问，在大学期间，你们对CCF认证或者英语四六级的考试的重视程度远远大于上述的两个认证，并且从师兄师姐那里并未据说公司以及导师招收研究生时对上述证书有要求，甚至在网上的大部分评论说这些证书比较“鸡肋”，远远比不上网络工程师等证书含金高。因此我也有点疑问:做为计算机专业学生是否须要考取这些证书呢？编程

问题1.3 多个同类型变量的实体不能在同一行定义吗？

更严格的说不要把多个变量定义在同一行上性能优化
Foo foo1,fool2; //bogus

尽管代码规范并无一个彻底肯定的标准，可是我对这个不容许多个变量定义在同一行的要求仍是有些不解。我我的习惯是将同类型的变量放在一行上，不一样类型的变量会分开行，可是按照这条要求来讲，假设如今代码中出现三个学生实体，须要一行行定义这几个实体吗，以下所示:服务器

typedef struct{
    ...
}Student;

int main(){
    Student student0;
    Student student0;
    Student student0;
}

总以为这样写有点冗余，可否请老师解释一下这个的分行写的缘由以及不分行写的坏处吗？网络

问题1.4 变量命名

书上也对变量作出了必定的要求，我对书上所说的持确定态度。恰好这个寒假作冯如杯的时候由于牵扯网页开发全部接触了一些js脚本，可是看到不少js脚本中的全部代码都是一行并且不少变量名都是以a b c这种简单的单字母命名。上网查阅资料说压缩为一行以及采用极简不可读的变量名是为了更快的加载渲染速度，我对这种作法比较怀疑，十分怀疑代码的可维护性。请问老师对这种行为有什么见解呢？数据结构

问题1.5 goto语句的使用

函数最好有单一的出口，为了达到这一目的，可使用goto。编辑器

书上说为了实现单一出口，使用goto语句跳到函数/方法的末尾，我认为这个跟直接在每一个返回点上直接写return语句并无本质上的区别。并且在前期全部编程课程上(好比数据结构，编译原理等)老师都强烈反对使用goto语句，我反对书上的这个观点。

问题1.6 类以及面向对象编程

仅在必要的时候，才使用"类"

若是只是数据的封装，使用struct便可

类不能滥用这点比较赞同，以上学期的编译原理课程设计过程为例，编译过程自己就是一个串行化比较高的过程，这个时候强行把语法分析、中间代码生成、代码优化建立一个类实际上是至关于给一些过程函数强行封装了一些类的外观，本质没有什么改变，反而增长了代码理解上的困难。可是后面我想请问，为何数据的封装尽可能不要使用c++的class呢，是由于效率的问题吗？

问题1.7 结对编程

在开发层次，结对编程能提供更好的设计质量和代码质量，两人合做解决问题的能力更强。

不适合结对编程的状况——.......

首先针对第一个课本阐述的结对编程的优势，在我看来优势并非绝对的，并且是理想化的，不一样同窗在编程的时候的设计和思路差别会很大，若是两我的一块儿结对很大几率会出现两我的分歧很大，没法谈拢，因此我认为在考虑项目是否须要结对编程的时候须要考虑到这个因素。
另外，对于下面的，课本上着重介绍了不适合结对编程的情形，可是什么状况下应该采用结对编程(我认为不是除了不适合以外的补集吧，有些状况下适合用结对编程可是没有必要，好比两个能够并行的项目开发并且须要在较短期完成，这时候可能每人各负责一块会效率更高)，何时采用并行编程？

问题1.8 敏捷流程

敏捷编程最重要的一个前提就是scrum master要将当前的任务切成一个一个的小块进行分配。可是在实际工做中，有些任务并无严格的独立模块，这种状况下如何进行划分，换言之，若是两个冲刺之间有前驱和后继的关系，可能会出现前驱的滞后会影响后继事件的推动与进程，这种状况该如何处理。scrum大师究竟在中间起到什么做用，为何不让两个程序员直接进行沟通，而必须经过master做为中介传递信息？同时，这个过程是否过分依赖scrum master的我的能力了(从master的职能来看，团队的运做很大程度依靠他的任务分配和分工协做)？

问题1.9 一个领域的创新真的跟本领域的专家关系不大吗？

16.1.5 迷思之五: 要成为领域的专家，才能创新

为何领域的专家有时候没有领域外的创新者那么有新意？这也是一个颇有意思的话题

我对这个观点总体上持确定态度，诚然，万事万物都不绝对，并不是成为一个领域的专家才能创新。可是我对书上所说“70%的创新者说他们最成功的创新是在他们的拿手领域以外发现的”这个70%的比例有些存疑，我认为领域外的创新是存在的，可是在整个领域的创新所占的比例是较小的。大部分创新点的提出是基于对该领域有着深入的理解与知识储备的，除此以外还有运气和灵光的成分。某领域内若是一个外行能够提出一个创新点，我认为后者是主要的因素，可是对于这个领域与行业的长久发展以及推动做用每每仍是这个领域的专家所完成的。

问题1.10 如何在程序的性能代价和程序开发代价之间找到合适的平衡点？

看了课本以及以前课程、网络上了解到的知识，程序开发效率强调封装以及代码重用，良好的扩展性。可是遗憾的是每每过多的封装、代码重用以及为拓展性增长的编码每每会拉低程序的执行效率，从而影响程序的性能。因此在实际开发中，咱们应该如何解决这二者之间的平衡问题呢？

2.请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 什么时候、何地、何人？

软件：

软件的第一个理论诞生于1935年，计算机之父阿兰图灵提出了软件理论。可是同时也有人认为软件正式出如今1958年John Turkey的论文中。

软件工程：

Margaret Hamilton 在1968年北大西洋公约组织在联邦德国召开的国际会议上为了讨论软件危机课题，正式提出并使用“软件工程”这个名词。

3.你们知道了软件和软件工程的起源，请问软件工程发展的过程当中有什么你以为有趣的冷知识和故事？

1)冯诺依曼的轶事

“有个著名的苍蝇问题，两人骑车从相距20英里的两地相向行驶，两人均保持稳定的10英里时速，一只苍蝇以15英里的速度从一辆车前轮飞向另外一辆车轮前轮，飞到时再折返，直到被两车前轮挤扁。

问题是：这只苍蝇一共飞行了多长距离？（这个中国学生都会）

笨办法是算出第一段从一车轮到另外一车轮距离，再算下一段，以此类推，最后全都加起来。
聪明的办法是注意到两个自行车从开始到相遇一共用时1小时，因此苍蝇也飞了1小时，距离就是15英里。”
当这个问题抛给冯·诺依曼的时候，他当即解答出来了，还显得对提问者很失望。
“噢，你必定早知道这个题的技法了！”
“什么技法？” 冯·诺依曼问道，“我就是作了无穷数列求和而已。”

1975年，艾伦和盖茨给Altair 8800计算机写了个BASIC解释器卖给MITS，他们很快完成了解释器，甚至包括本身的IO系统和编辑器，一共只须要4k内存。不过最后他们发现还须要一个引导程序将这些东西从外存整进去。 Paul Allen在飞机航班上完成了这项工做。这是1975年，没有笔记本。他用的是纸笔。写的是8080机器码。

注：以上两个故事来源知乎

4.上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些，各有什么优缺点？

从维基百科中能够看出来近年来流行的源程序版本管理软件的流行状况。

很遗憾的是表中并无Mercurial / Trac / Bugzilla 这三种工具的用户数，下面将依次列举一下git /Mercurial / Trac / Bugzilla 这四种源程序版本管理软件的优缺点。

git(包括github和gitlab)
- 优势:
  - 可用性好，十分方便；
  - 用户多，项目多，利于交流学习；
  - 有本身的十分强的功能（pull request,issue）等
- 缺点:
  - 对中文支持太差；
  - 前期学习知识较多
bitbucket
- 优势:
  - 支持私有免费项目；
  - 提交大文件速度快。
- 缺点:
  - 不容易找到项目；
  - 社区活跃度不是那么大。
Mercurial
- 优势:
  - 照顾命令行用户，大多数命令都有双字母的简称，效率更高。
  - 照顾SVN的迁移用户，命令上大多数都继承自SVN，使得用户更加习惯。
  - 基于Python，服务器配置相对于Git更加容易。
- 缺点:
  - Mercurial的branch管理和Git相比不方便，branch出来就删不掉。
Trac
- 优势:
  - 十分灵活，支持定制；
  - Trac有良好的扩充性；
  - Trac的权限体系是比较完备的设计。
- 缺点:
  - 不支持多项目；
  - 对中文的支持差；
  - 需求和缺陷没有分离。
Bugzilla
- 优势:
  - 定制功能很强；
  - 对语言的支持很强；
  - 免费，响应速度较快。
- 缺点:
  - UI设计差；