| 项目 | 内容 |
|---|---|
| 作业所属课程 | 软件工程班级博客 |
| 作业要求请点击链接查看 | 作业要求 |
| 我在这个课程的目标 | 学习如何用工程化方法构建和维护软件 |
| 这个作业在哪个具体方面帮助我实现目标 | 通过阅读《构建之法》，认识了解软件工程 |
一.阅读教材后的问题
1.第3章 软件工程师的成长
我看了这一段文字
这个毛病早就被归纳为“过早的优化是一切罪恶的根源”。
有这个问题：什么是过早的优化？什么是合理的优化？如果全局过于大，又是否要去了解完全局后，再决定是否优化以及怎么优化？
2.第4章 两人合作
我看了这一段文字
结对编程中驾驶员和领航员的角色要经常互换，避免长时间紧张工作而导致观察力和判断力下降？
有这个问题：在这里使用驾驶员和领航员用作类比是否不恰当？其次，是否专精一个岗位比经常交换好？我查了资料，赛车中的驾驶员，是负责快速按照指令完成驾驶动作的，领航员则要负责观察道路，给出车速和挡位的建议，以及驾驶指令。可以说两者需要的能力是有区别的，很难交换。在结对编程中，经常互换，会不会导致思路打断，或者产生冲突等等，降低效率。
3.第4章 两人合作
我看了这一段文字
如何正确地给予反馈。1.最外层：行为和后果。2.中间层：习惯和动机。3.最内层：本质和固有属性。
有这个问题：在书上例举的例子中，选择最外层的方式的效果是最差的，而选择最内层的方式的效果是最好的。那么是否每次选择的结果，就一定是这样呢？我发现书上尽管是在讲如何正确地给予反馈，但是举的例子都是在指出不足，那表达感谢又该如何正确地给予反馈呢？我想到了一个例子，想表达别人代码写的好。最外层：你这次的代码写的很好，我相信我们会取得好的成绩。中间层：你一直都习惯不断的完善代码，很富有责任感，想把自己的部分做好，使得整个项目更好。有你在这个团队，我感到很高兴。最内层：你是一个精益求精，一丝不苟的人，做什么事都很认真，很努力，果然你这次写的代码，依然很好。因此我的疑惑是，如何正确地给予反馈，是否还要考虑情感因素，来选择最内层或是最外层。
4.第16章 IT行业创新
我看了这一段文字
这些故事的另一个引申是——他们都是独立工作，没有一个阿基米德团队或者“牛之队”在背后支持。
有这个问题：伽利略的自由落体定律和开普勒的行星运动规律算不算“牛之队”在背后支持？我查了资料，尽管这些科学家和牛顿并没有直接共事，但他们和牛顿都有共同的目标——解释天体运动问题。他们为牛顿提出他划时代的理论，提供了坚实的理论基础，我认为这属于一种有共同目标的团队的背后支持。同时开普勒定律的提出，也不是独立工作的结果。在开普勒与第谷共事十个月后，开普勒利用第谷留下的大量的宝贵的资料，最终提出了开普勒定律，这也是共同合作的宝贵成果。
5.第16章 IT行业创新
我看了这一段文字
近代以来，很少能有人独立推出前无古人的发明创造。
有这个问题：这是属于人的问题，还是属于时代或社会发展问题？我查了资料，我觉得有三方面原因，一.科技黑箱的出现，科技知识和其他要素被集成于某种框架之中，并不需要知晓里面运用的技术，只要能执行操作满足需求就好。二.随着科学技术的不断产生、分化、延伸，一个人需要花很多时间，去掌握一门特定方向的有局限性的技术，但发明创造常常需要多门技术的协作。三.如今的社会，非常讲究节奏和效率，团队协作带来的在进度方面推进的优势被大大体现，也就让人很难去选择独立发明创造。由此我得到了另一个疑惑，随着人类社会的发展，独立推出发明创造是不是将越来越难？
二.请问 “软件” 和 “软件工程” 这些词汇是如何出现的
- “软件”一词是由John Tukey在他1958年的论文《具体数学教学》中提出的。
- “软件工程”一词是Margaret Hamilton在1969年前后，在阿波罗计划期间发明创造出来的。
三.软件工程发展的过程中有什么你觉得有趣的冷知识和故事
1975年，艾伦和盖茨给Altair 8800计算机写了个BASIC解释器卖给MITS，他们很快完成了解释器，甚至包括自己的IO系统和编辑器，一共只需要4k内存。 不过最后他们发现还需要一个引导程序将这些东西从外存整进去。 Paul Allen在飞机航班上完成了这项工作。这是1975年，没有笔记本。他用的是纸笔。写的是8080机器码。
来源：知乎
四.目前流行的源程序版本管理软件和项目管理软件及其优缺点
| 软件 | 优点 | 缺点 |
|---|---|---|
| Git | 适合分布式开发，强调个体。公共服务器压力和数据量都不会太大。速度快、灵活。任意两个开发者之间都可以很容易地解决冲突。离线工作。 | 学习周期较长。不符合常规思维。代码历史保密性差，一旦开发者把整个库克隆到本地，就可以完全查看到所有的历史版本信息。 |
| Mercurial | 更简洁好用的命令行指令。上手简单。完善的GUI支持。易于扩展。 | Mercurial的分支模型十分复杂，每一种分支方法都有很多缺点和不便之处。Mercurial改写历史很麻烦。没有命名空间。 |
| Trac | 非常灵活，可以随心所欲地定制。可以和SVN集成。 Trac的权限体系是比较完备的设计。 | 不支持多项目。中文化不完整。核心功能很少，不安装插件基本无法使用。 |
| Bugzilla | 检索功能强大。强大的后端数据库支持。根富多样的配置设定。 | 安装需要Perl和配置MySQL数据库，过程比较繁琐。 修改配置文件很麻烦。流程无法定制。 |
| 软件 | 用户量 |
|---|---|
| Github | 约31,000,000用户量 |
| SourceForge | 约3,700,000用户量 |
| Bitbucket | 约5,000,000用户量 |
| GitLab | 约100,000用户量 |