软件工程第一次阅读作业

软件工程第一次阅读作业

本作业属于软件工程
本作业要求

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

第一个问题：究竟是对计算机各种领域都有所涉猎，还是专精其中之一，对我们今后的职业生涯更有帮助呢？
在《构建之法》的第三章里，作者提及了专与精的关系，但又浅尝辄止，并未深入讨论。在此我不免产生疑问：对于我们以后的职业生涯来说，到底是对各种领域各种技术都有所涉猎，还是专精一种比较好呢？一般人都会希望自己会的越多越好，对于自己所开发的项目方方面面都能掌握，甚至自己独立开发。然而小的项目还好，大型项目几乎是不可能自己独立完成的。但尽管如此，多方涉猎是否还是更好一些呢？

第二个问题：结对编程中两个人具体的职责是什么？能否给出一些实例进行说明？
在《构建之法》的第四章里，作者一开始是这么描述结对编程的：

在结对编程模式下，一对程序员肩并肩、平等地、互补地进行开发工作。他们并排坐在一台电脑前，面对同一个显示器，使用同一个键盘、同一个鼠标一起工作。他们一起分析，一起设计，一起写测试用例，一起编码，一起做单元测试，一起做集成测试，一起写文档，等等。

看到这里，我想象中的结对编程的两人是一起做设计一起实现，两人同坐一台电脑前一边讨论这个功能该如何如何实现，一边进行编程，似乎结对编程也就是两个人一起写同一份代码而已。然而后面又有对驾驶员与领航员各自职责的介绍：

1.驾驶员：写设计文档，进行编码和单元测试等XP开发流程。
2.领航员：审阅驾驶员的文档；监督驾驶员对编码等开发流程的执行；考虑单元测试的覆盖率；思考是否需要和如何重构；帮助驾驶员解决具体的技术问题。领航员也可以设计TDD中的测试用例。

这里似乎又把两个人的关系割裂了开来，一个做设计与开发工作，而另一个则负责监督与部分测试。这里似乎与前面产生了矛盾。
我对此的疑问是：假如两个人坐在同一台电脑前一边讨论一边编程，那么划分驾驶员与领航员又有什么意义？因为如果设计与编码过程都是两个人一起讨论的结果，那么驾驶员写文档、写代码也不过只是负责把两个人讨论的结果输出到电脑上而已，谁都可以做，甚至还可以有第三个人在这里只负责打字，做个人肉打字机，将这两人的讨论结果输出到电脑上。这样与结对编程似乎并没有区别。而假如领航员只是全程在旁观看监督驾驶员进行开发工作，起到“旁观者清”的作用，可以提醒驾驶员他犯的某些小错误，这似乎又是一种人力资源的浪费。

第三个问题：子瀑布模型的具体含义是什么？
在《构建之法》第五章里，作者提到了子瀑布模型：

-大瀑布带着小瀑布
为了解决不同子系统之间进度不一，技术要求迥异，需要区别对待的问题，有人引入了子瀑布模型

在这种瀑布群下，要把各个子系统统一到最后做系统测试（System Test）的阶段，难度不是一般的大啊！另外，在这样的开发流程中，用户只有到了最后才能看到结果，用户真是等不起。

我对此的疑问是：不同子系统具体是指什么？如果是指同一系统下负责不同功能的各个子系统，那么最后的统一工作似乎并没有那么大的难度吧？如果是指同一系统针对不同用户的不同版本，似乎又有些没有必要。

第四个问题：关于敏捷开发的几点疑问
在《构建之法》第六章里，作者提到了敏捷开发的原则：

敏捷开发的原则是：
1.尽早并持续地交付有价值的软件以满足顾客需求
2.敏捷流程欢迎需求的变化，并利用这种变化来提高用户的竞争优势
3......
......

其中，仅就前两条原则来说，似乎是在鼓励我们尽早地做出第一个版本交付给客户，此后不断在原来版本的基础上做修改形成新的版本交给客户。这似乎是在鼓励我们采取在第五章中作者提到的写了再改模式，然而这并不是一个好的开发流程。对于我个人来说，在之前的一些比较基础的课程如大计基、数据结构等课程中采取的就是这种模式，每次都是看过需求之后上手就写，不对再改，改对为止。这种非常差的编程习惯导致我在面对计组、面向对象这样的系统性大型工程开发课程时遇到了比较大的困难。所以是否是我理解有误？
另外还有一个疑问是：第二条原则鼓励我们面对需求的变化，然而我们在快速完成初始版本时，是无法预先得知后续会有什么样的需求变化的，因此这会为我们面对后续需求变化时带来麻烦。比如在面向对象课里，在无从得知后续新加功能是什么的情况下，我在写第二次电梯作业时几乎是把第一次电梯作业的代码完全推倒重来的。这种情况该如何应对呢？

第五个问题：软件行业真的就是赢者通吃，败者或者是后来者没有翻身的余地吗？
在《构建之法》第十六章里，作者在介绍黄金点游戏的规则的时候，提到了下面这段话：

赢者通吃
这个游戏规定第一名得到全部的分数，第二名（不管多接近）到倒数第二名都是0分，最后一名还要到扣分。软件行业就是一个赢者通吃的环境，最后一名还要把自己的身家倒贴进去。

当初的苹果在软件行业是当之无愧的霸主，然而就是因为他们对微软的轻视，导致了微软做大，将苹果挤下了第一的宝座；同样的，谷歌也是在微软帝国的夹缝中成长起来，硬生生成为搜索引擎界的霸主的；而意气风发不可一世的谷歌最终也是在中国输给了百度，最终退出中国市场；在第十六章迷思之四中也提到了Intuit公司打败了微软成为了个人财务软件时长的霸主。这些例子似乎并不符合赢者通吃的说法。

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

“软件”这一词汇是在1953年8月由Richard R. Carhart在兰德公司的研究备忘录中提出的，“软件工程”这一词汇是在19世纪60年代由Margaret Hamilton在早期的阿波罗登月项目中提出的。

三、上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？请按照最近一两年使用人数的多少， 从多到少排序并说明各自有多少用户（估计），工具的优缺点（可以引用相关资料并注明来源）。

来源：https://en.wikipedia.org/wiki/Comparison_of_source-code-hosting_facilities

• git
  • 优点：
    • 适合分布式开发，强调个体。
    • 公共服务器压力和数据量都不会太大。
    • 速度快、灵活。
    • 任意两个开发者之间可以很容易的解决冲突。
    • 离线工作。
  • 缺点：
    • 资料少（起码中文资料很少）。
    • 学习周期相对而言比较长。
    • 不符合常规思维。
    • 代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。
• Mercurial
  • 优点：
    • 有revset
    • 扩展性好
    • append only的存储结构
  • 缺点：
    • 强制向下兼容
• Trac
  • 优点：
    • 扩充性好
    • 权限体系完备
    • 非常灵活
  • 缺点：
    • 不支持多项目
    • 中文支持较差
    • 核心功能很少
• Microsoft TFS：
  • 优点：
    • 任务版上能将需求、项目进度一览无余，对于小团队而言，比甘特图更有用，集成了项目管理、版本控制、BUG 跟踪，能有效实现 SCRUM，能与 VS 无缝接合。
  • 缺点：
    • 搭建、维护tfs比较复杂，硬件要求也比较高。
• GitHub：
  • 优点：
    • GitHub是一个非常万能的工具。对于任何大小的项目，他都是理想的工具；他也是伟大的web工作流工具。首先，他可以作为一个版本控制系统和协作工具，用它来发布工作。
    • 利用GitHub，你可以将项目存档，与其他人分享交流，并让其他开发者帮助你一起完成这个项目。优点在于 ，他支持多人共同完成一个项目，因此你们可以在同一页面对话交流。
    • 创建自己的项目，并备份，代码不需要保存在本地或者服务器，GitHub做得非常理想。
  • 缺点：
    • 学习成本较高，需要通过较长时间的学习、熟悉后才能流畅使用各种命令
• BUGZILLA：
  • 优点：
    • BUGZILLA不收费,
    • BUGZILLA现在有中文版支持
  • 缺点：
    • BUGZILLA只能管理缺陷
• Apple XCode：
  • 优点：
    • 可以自动创建分类图表。
    • 自动提供撤消、重做和保存功能，无需编写任何编码。
  • 缺点：
    • 更新版本后，某个插件可能会失效。

来源：https://www.cnblogs.com/yuyue1216/p/5281544.html
https://zhidao.baidu.com/question/877348900365484132.html
https://www.cnblogs.com/bgwhite/p/9403233.html