个人博客作业(1)

项目	内容
这个作业属于哪个课程	2020计算机学院软件工程(罗杰任健)
这个作业的要求在哪里	个人博客作业
我在这个课程的目标是	学习和掌握软件工程中的各种技巧和方法，提高自身的工程能力和编程能力
这个作业在哪个具体方面帮助我实现目标	速读软件工程的书籍《构建之法》，学习其中的软件工程方法，学习如何提问并提出自己对于书中内容的疑问

一、速读《构建之法》后存在疑问的5个问题

1. 单元测试要由最熟悉代码的作者来写吗？

2.1.2 好的单元测试的标准

......
代码的作者最了解代码的目的、特点和实现的局限性。所以写单元测试没有比作者更合适的人选了。
......

我对这一点其实挺奇怪的，如果代码的单元测试是由代码的作者来写，那么写代码的时候没有考虑到的问题，在写单元测试的时候也不会有考虑到；同样，单元测试时所测试的部分必然是在写代码的时候就被考虑过了，那么作者写的单元测试的作用只能检测所写代码是否按照作者的想法运行，无法检测代码是否满足需求，最后代码的质量是否能够得到保证又回归到作者是否可靠上。一个写代码的时候没有充分考虑的作者，他的单元检测也是不充足的；一个足够可靠的作者，他的代码也是足够可靠的，那么无法通过单元测试的形式保证代码的可靠。

2. 结对编程中如何解决由一方占主导的问题？

4.5.2 为什么要结对编程

......
在结对编程中，因为有随时的复审和交流，程序各个方面的质量取决于一对程序员中各个方面水平较高的那一位。
......

当结对的双方的水平有差异的时候，如何避免水平较高的一方获得过高的话语权成为开发的主导，使得另一方的功能被弱化，形成类似师傅带徒弟的情况而非驾驶员和领航员的角色。还是编程水平差距比较大的双方不适用于结对编程。

3. 作为一个软件工程师，是否应该参与用户需求的调研？

8.3 获取用户需求————用户调研

这个问题的来源不限于这章的具体的某段话。用户的需求是模糊的，隐含的，很多公司对于用户的需求这方面都有专门的团队负责，他们有专门的工具，掌握心理学等专业知识，从用户模糊的反馈汇总提取用户的专门的需求。工程师必然会和这些部门合作和交流，但是否有必要使用焦点小组和深入面谈这些方式直接接触用户，从中提取用户的需求，而不是将其交给更专业的人。

4.现在的创新真的不需要成为领域内的专家吗？

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

其中列举的诺基亚和索尼的例子不是很合适，诺基亚投身通讯业的时代是通信业飞速发展的时代，这时的通讯业是个非常大的蓝海市场，而且其中技术非常新，是一个行业开始积累的时间，而到了现在，诺基亚凭借自身的积累成为通信行业内的专家，依然在5G等规则的制定中有着不小的话语权。而索尼则一直是影视频播放设备的龙头老大，Walkman的成功并不是因为他不守语法的名字，正是因为索尼对于需求的准确把握和自身足够的实力带来的，这与语言学家完全没有关系，相反索尼是这其中的专家。而到了现在，很多行业早已不是发展的初期，已经积累的大量的理论和技术，在这些行业内部做出足够成功的创新，必然要掌握现行的这些理论和技术。这就成为了其中的专家。

5. 如何磨合团队，如何避免假团队和建立起团队内部的互相信任

17.3 领导力

这张中讲述了团队从萌芽阶段、磨合阶段到创造阶段的特质和关键，其中磨合阶段中第一个关键是信任，但只解释了信任如何重要，没有提出建立信任的方法。

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

维基百科里提到，软件(software)最早出现于约翰·图基在1958年发布的论文"The Teaching of Concrete Mathematics"1。
同样维基百科中提到，软件工程(software engineering)一词有多个来源，最早见于1965年出版的电脑与自动化杂志上，并在1966年的ACM会议上被正式使用2

三、大家知道了软件和软件工程的起源，请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事？

早在雅达利2600上的游戏《Adventure》上，当时的制作人 Warren Robinett 就曾在游戏内留了一行彩蛋“Created by Warren Robinett”。这是因为当时雅达利十分害怕同行挖墙脚，不在游戏中放出完整制作者名单。Warren Robinett 当时干这事儿的时候，谁都没告诉，包括自己的顶头上司——但最后他还是离开了公司。
最早的彩蛋

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

软件	优点	缺点
Github	有大量用户和开源项目；提供Git存储库；外网使用速度快，灵活，但国内不是很理想；良好的分支和代码版本管理	资料少，学习成本高；代码保密性差；
Microsoft TFS	对敏捷开发支持好，集成了项目管理、版本控制、BUF追踪等功能；任务板能很好的展示需求和进度，对于小团队来说比甘特图好用；	搭建、维护tfs复杂，硬件要求高；使用不便，大部分公司、团队只能使用到源码管理这部分的功能
Bitbucket	同时支持Hg和git；支持中文；对大文件友好	系统稳定性差
Mercurial	简单，易上手；拓展性强；封装好；	分支管理不灵活；跨平台性能差
Apple XCode	编译速度快；自动提供撤消、重作和保存功能，无需编写任何编码；可以自动创建分类图表	插件的支持不是很好，版本更新可能会导致插件失效
Trac	非常灵活，权限设置较为完善，可以非常棒的管理和SVN集成	本身功能少，极度依赖插件;需求和缺陷没有分离；不支持多项目；中文支持差；文档编写工具门槛高
BUGZILLA	检索功能强大;审核机制安全;网络用户界面友好；安全策略细致和产品分类方案完备；	只能管理缺陷

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
来源wiki