软件工程第二次作业——个人博客作业

一、阅览教材/讲义后问题汇总

1）PSP: Personal Software Process：每个人的工作质量直接影响最终软件的质量？

读到“每个人的工作质量直接影响最终软件的质量”这一段话，我有一个小问题：也许只有团队中少部分人真正影响了最终软件的质量呢？当经过软件的设计与任务的分配，团队不免会有“划水”的人存在，也就是非P1的人，他们的工作无非只会延长成果的完成时间。而团队中能力较强的人能够完成这些“额外”单工作，将进度拉回正轨，最终的软件质量也就不受影响了。

2）技能的反面：技能的反面是problem solving？

读到“技能的反面是Problem solving”这句话，我存在疑惑。这里对Problem Solving的解释有些生硬，将其意思约束在了能力差的人的行为表现。然而Problem Solving也是一项能力，如果一个人称自己精通编程，在被要求用特定语言完成一个问题的情况下，通过“Problem Solving”迅速了解了这门语言的基本用法，并完成了题目，这又何尝不是技能的精通呢？

3）结对编程测试的极致做法是TDD？

文中对极限编程的表格中，有这么一项：“测试/单元测试能帮助提高质量”的极致做法是“先写单元测试，从测试开始写程序——TDD”。通过网上查阅得知，TDD的基本思想是在开发功能代码之前，先编写测试代码，其理念是

确保所有需求都能被照顾到
在代码不断增加和重构的过程中，可以检查所有功能是否正确

从上述的解释来看，如果需求在不断改变，一旦某段实际功能代码作废，其测试代码也将报废。若面临软件重构的情况，带来的测试程序的改动将是十分巨大的。此外，如果只根据需求分析编写测试程序，而不去考虑实际程序，结果测试只能覆盖结果的正确性，而无法保证其实现过程正确，程序的bug往往出现在对实现细节的考虑不周。

因此，我对“测试能提高质量的极致是TDD”的推理仍存在疑惑。

4）敏捷宣言：敏捷求成品，而不需要文档？

读到现有做法与敏捷的对比表格：“现有的做法：完整的文档；敏捷的做法：可用的软件”，我存在一些疑惑。面向对象程序设计课程中教给我们，编码之前应充分设计，且需充分考虑其可扩展性，在实践过程中，我发现明确的设计文档确实对编码思路、增量开发有很大帮助。而敏捷目标在于“可用的软件”，当遇到需求的变化时，没有经过充分设计的文档指导与代码支撑，增量开发会不会变得十分困难，反而不那么“敏捷”了？

5）画扇面：速成还是求全？

博客中利用画扇面的例子形象描述出软件工程团队项目进展，引起了我的思考：如果团队项目在进行中途不断添加需求，最终会导致问题层出不穷复杂从而项目流产，那么团队在最初的需求分析时，应该尽可能将需求简化，以达到“速成”的目的，还是应该将需求的功能充分考虑呢？

以我的个人经验来看，如果作为学生，项目的最终目的是为了的高分，那么前期的充分需求分析、创新性想法就成了争夺高分的利器，而且在准备做足的基础上，项目进展的加速度大，动力也足；而如果追求敏捷而抛弃充分分析的话，导致成果得分不高的同时，还会出现项目完成时处于距离交差不上不下的时间、没有动力增加新功能的窘况。当然在如果交差时间很局限的话，削减需求、敏捷开发还是很必要的。

6）创新的迷思连载(2)：技术创新不一定是关键？

在“迷思之六-技术的创新是关键”一节中，作者的观点是，除了技术的创新，其他方面的创新也显得尤为重要。而我认为，相比于其他创新带来的昙花一现，技术的创新才是关键。ipod成功的真正原因并不是用户界面上的创新，而是它实现了“把1000首歌塞进口袋”的技术；苹果生态能够取得成功，得益于其内部软硬件技术的一次次创新；网络购物理念出现时，Paul Graham使用Lisp语言编写Viaweb，在技术上一直领先竞争者，并具有更快的迭代速度，从而占据领先地位。其他方面的创新固然能产生显著效果，比如共享经济、电商经济，但谁才能真正享有成功的果实？只有技术创新才能带来一骑绝尘的实力。因此，对于作者在“技术的创新是关键”的迷思上，我存有疑惑。

二、“软件”、“软件工程”词汇的产生

“软件”的产生

In 2000, Fred Shapiro, a librarian at the Yale Law School, published a letter revealing that Tukey's 1958 paper "The Teaching of Concrete Mathematics" contained the earliest known usage of the term "software" found in a search of JSTOR's electronic archives, predating the OED's citation by two years. This led many to credit Tukey with coining the term, particularly in obituaries published that same year, although Tukey never claimed credit for any such coinage. In 1995, Paul Niquette claimed he had originally coined the term in October 1953, although he could not find any documents supporting his claim. The earliest known publication of the term "software" in an engineering context was in August 1953 by Richard R. Carhart, in a RAND Corporation research memorandum.

上文中说明了“软件”一词的3种起源：

1958年Tukey在论文《The Teaching of Concrete Mathematics》中包含了“软件”一词的最早用法
Paul Niquette 声称自己在1953年10月创造了“软件”这个词，经管他找不到支持他说法的文件
“软件”在工程领域的最早出现是1953年8月Richard R.Carhart在RAND公司的研究备忘录中

“软件工程”的产生

Hamilton details how she came to make up the term "software engineering":
When I first came up with the term, no one had heard of it before, at least in our world. It was an ongoing joke for a long time. They liked to kid me about my radical ideas. It was a memorable day when one of the most respected hardware gurus explained to everyone in a meeting that he agreed with me that the process of building software should also be considered an engineering discipline, just like with hardware. Not because of his acceptance of the new 'term' per se, but because we had earned his and the acceptance of the others in the room as being in an engineering field in its own right.

“软件工程”是在1960s阿波罗计划执行期间由Margaret Hamilton提出。上面是Margaret Hamilton描述自己如何提出“软件工程”这一词汇的细节。

三、软件工程发展的过程中的冷知识

Unix的命名：上世纪六七十年代，计算机工业几大巨头聚在一起，合作研发官方版的下一代操作系统Multics。但是，另外两个年轻人——26岁的肯·汤普森和28岁的丹尼斯·里奇——觉得Multics过分负载，就另起炉灶，写出了一个自己的操作系统。他们参照Multics，为它取了一个搞笑式的名字Unix（注：前缀Multi-意思是“多个”，而前缀Uni-意思是“单个”） ——《黑客与画家》

四、源代码与项目管理软件调研

目前主要流行的源代码和项目管理软件有Microsoft TFS，GitHub，Trac，Bugzilla，Apple XCode等。优缺点如下：

	优点	缺点
Microsoft TFS	对敏捷、CMMI等项目、过程管理改善有较好支持，需求、项目进度一览无余，对小团队开发有利	用户量少，源代码功能使用较多，但并不是软件定位
Git	支持多人维护庞大项目，分支能力强大、体验好，支持离线提交、非线性开发，是的协作流畅	上手难，代码保密性差
Mercurial	命令行简单，易上手，可扩展性好，对网络依赖性低	功能较弱，分支方式杂多不便，改写历史麻烦；没有命名空间，容易混淆
GitHub	基于web，允许使用Git的源代码管理功能，开源	适合代码跟踪，但不适合设计跟踪，对国内用户不友好
Bitbucket	免费支持私有仓库，且同时支持hg/Git，自定义域名，有Bug追踪功能	鲜为人知
Trac	有良好的扩充性，权限体系的设计较完备，灵活、可随心所欲定制	不支持多项目，核心功能少，中文化不完整，本地化很差
Bugzilla	bug管理系统，检索功能强大，后端数据库强大，配置设定丰富多样	安装繁琐，不支持中文
Apple XCode	文件转移快速，可自由撤销，能够辅助开发	只支持Mac OS