第一次阅读作业

软件工程第一次阅读作业

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

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

问题1.1 第二章 个人技术和流程

单元测试必须由最熟悉代码的人(程序的作者)来写。
单元测试应该覆盖所有的代码路径。

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

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

职业发展——考级之路

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

​这个我有一定的疑问，在大学期间，大家对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设计差；