一、一些疑问
看书看得比较慢，暂时只思考了以下几个问题，有些自问自答，不知道符合不符合要求……
【1】
第一章中书上提到了这样一个例子：
“如果一架民用飞机上有需求，用户使用它的概率是百万分之一，你还要做这个功能么？”
对此我有个问题：如果这个功能和飞机的安全性能无关，那么还需要实现这个功能吗？
我一开始的想法是，是否实现这个功能是要根据价值期望（被使用的概率*它的重要性）来决定，对于安全功能，即便它被使用的概率很小，但是它的重要性很高，因此价值期望也就很高。但是后来我考虑到，实现一个功能需要一系列代价，包括开发精力、对运行速度的影响、对稳定性的影响等等……如果飞机的安全保障需要花费庞大的人力和财力（比目前的还要再高不少），这个功能真的还会被应用吗？
我大概想了一下，如果被应用了，可能是以下这个路线：
机票价格上升→大众负担不起→客户减少→公司破产……
这可能有点夸张，但是我正想用此表达我的疑问：开发成本和产品安全性之间应该如何抉择？我认为在这种情况下，产品安全性的地位不是绝对的，只要不虚假宣传，买不买机票是乘客说得算的。如果乘客认为不值得花费更高的金额去换取百万分之一的安全，他有权利选择价格更低的机票。所以最好的办法或许是造出两种飞机（就好像经济舱和商务舱），让乘客决定哪一种更适合自己。实际上现在很多软件也分为“社区版”和“专业版”，后者比前者功能更强大也更稳定，但是要贵得多，不知道这和上面的例子有没有关系呢……？
【2】
第二章中提到了用“单元测试”去检测代码的正确性，对此我有个疑问：单元测试的正确性应该如何保证？是否还需要写一个单元测试去检测单元测试呢？
我查了资料[1]，博文作者提到了“TEST FIRST”的观点，这一点在《构建之法》中也有提及。在开发之前先设计测试代码的的好处是，测试代码可以更加灵活、清晰，在不受到开发代码制约的同时，也为后面的开发明确了思路。与此同时，作者还强调测试应该针对需求进行，不应该涉及别的类，这倒是省了些工夫，但我个人感触不是很深，之前总感觉测试代码越详细越保险，不知道作者的想法是否有可取之处。总的来说，作者的观点是对于开发人员，测试要针对需求，更加细致的测试是测试人员干的事情。那么也就是说OO还有这次软工个人作业的测试是为将来从事测试方面的工作打下基础？还是说这也是开发人员应该掌握的技能呢？
【3】
程序的可扩展性与运行速度应当如何取舍？就拿这一次作业来说，我是采用了在模板上变换的做法来生成数独，这样的优点是很快，但是缺点是生成的数独具有很大的共通性，算不上实用。如果后期老师又要求生成一亿个数独甚至更多，这种套路恐怕难以适用。
【4】
第四章书上特意提到了“只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto”。但是已经有人证明过goto语句的不必要性，而且自从大一开始学习c语言以来，老师、学长一再强调不要使用goto，会造成代码可读性下降，这一点和书上所写的不是矛盾的吗？
后来去了一些论坛看了看，发现使用goto的人好像也不少，毕竟存在即合理，但是使用goto的人都遵循着一个原则——不影响程序的顺序性，也就是说goto只能用于向下跳转，不能向上跳转。一般情况下，goto语句多被用于跳出多层循环，这一点我也在这次数独作业中进行了尝试，感觉还是很方便的。
但是让我不太明白的是，goto这种不被推荐的用法，有时候也能找到它的“用武之地”，那么如果团队明确规定“不允许使用goto语句”，这是不是一个合理的做法呢？这让我想到了很多团队都对一些代码规范进行严格的规定，比如大括号一定要换行，一定要用四个Space代替Tab等等……这些代码风格经常能成为论坛中的“引战帖”，可以看出各有优劣，那么强硬地要求使用某一种代码风格有没有必要呢？
【5】
第五章开头，作者强调了“团队”与“非团队”的区别——“团队目标一致，互相依赖合作，共同完成任务；而非团队成员则彼此独立，甚至可以随时脱离队伍”。非团队给我的感觉就是聘用者和受聘者的关系，leader给受聘者发放薪水，受聘者给leader打工，一分钱一分货。我于是在想，如果按照这种定义来看，岂不是企业中就不存在团队了？
但是仔细想了想，我觉得也不一定。衡量一伙人是不是一个团队不能只看薪水，而是他们在关心什么。团队的成员关心团队是否能够取得成功，而非团队的成员只关心还有没有工资可以拿。也就是说，即便拿了工资，偶尔也能关心一下项目进展，那么这也可以作为一个团队。
那么我的问题是，作为一个由“雇员”组成的团队，成员为什么会愿意关心团队的状况呢？在软工课上，之所以每一名成员都努力为团队做贡献，是因为团队的期末答辩拿到了高分，每名成员都可以收获不错的成绩。在创业初期的团队中，可能每名成员不仅可能吃不上饭，还需要付出相当大的努力。那么是什么维系着这个团队呢？大概是如果创业成功了，每名成员都将得到巨大的利益，这份利益完全对得起他们的付出。
我的理解是，团队之所以是团队，是因为团队的成功可以为每一个成员带来好处，如果一个吝啬的leader不愿意将队伍的成果分享给每一名成员，而仅仅用工资打发他们，那么我想成员也没必要再关心这个队伍的进展了。实际上，很多企业都会根据当年的业绩发放“年终奖”，这就是将团队利益共享的一个很好的方式。
所以我在想，是不是一个非团队，如果能够实现利益的共同化，它就可以变成一个团队呢？
二、“软件”和“软件工程”这些词汇是如何出现的？
1958年，Tukey发表了一篇题为“The Teaching of Concrete Mathematics”的论文，这是所知的“software”一词最早的用法。[2]
“software engineering”是Apollo计划中，Hamilton在MIT提出的，她想要给予软件“合法性”，就像其它工程学科一样。[3]
三、软件工程发展的趣事和冷知识
“I'm an egotistical bastard, and I name all my projects after myself. First Linux, now git.”
Git这个名字是Linus Torvalds在编写第一个版本的时候起的，他将这个工具自诩为“the stupid content tracker”（傻瓜内容跟踪器）。我从Git的官方wiki找到了关于这个名字的多种解释，用自己的渣英语翻译一下：
- 三个随机的、可发音的字母，并且它没有被作为任何UNIX的指令，它是被误读的“get”这件事变得无关紧要；
- 辣鸡、卑鄙、简陋，字典里的粗话随你挑；（该词在英国俚语貌似是脏话OTZ）
- 是“global information tracker”（全局信息跟踪器）的简写：如果你心情不错，并且它正常地运行着，天使们在歌唱，一缕阳光洒进房间；
- 是“g*dd*mn idiotic truckload of sh*t”的简写：如果它崩了……
四、上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？
其它的不太了解，Github在2013年用户数量突破了300万[4]，而且根据2016年GitHub的Octoverse报告显示，在过去一年中，来自中国的新用户注册增长最快，同比增长了97%，其次是印尼（90%）、印度（76%）、俄罗斯、巴西和日本。[5]
[GIT]
优点：
1.分支能力特别强大，体验特别好。加上支持离线提交，分布式推送拉取，使得代码层面的协作相当流畅；[6]
2.GIT的分支模型很全面很好用，可以自由地修改历史，方便多个版本库的交流。
缺点：
1.概念过于复杂；
2.命令行语法设计得比较随意且不一致；
3.命令行帮助提示晦涩难懂；
4.缺乏良好的封装；
5.对代码的维护者友好，但却牺牲了共享者的使用体验；
6.版本管理未必安全；
7.一些简单的操作需要用到过多的命令。[7]
[TFS]
优点：
1.任务版上能将需求、项目进度一览无余，对于小团队而言，比甘特图更有用；
2.集成了项目管理、版本控制、BUG 跟踪，能有效实现 SCRUM；
3.能与VS无缝接合。
缺点：
1.用浏览器访问相当慢；
2.从 IE 上访问、填写各种开发、测试记录，也是很慢，不如 mantis BT 这样基于 php 的那么方便、迅速。[8]
[Mercuria]
优点：
命令行简单、容易上手。
缺点：
1.Mercurial 在不同平台上（尤其 Windows 与 Linux 之间）有档名编码的问题，如果版本库可能使用到中文档名，会造成跨平台的交流障碍；
2.分支方式各有缺点和不便之处；
3.改写历史很麻烦，操作繁琐，难以还原错误操作之前的状态，更容易导致版本库混乱，也更容易出错导致丢失历史；
4.Mercurial 没有命名空间，一但和很多个版本库交流，很容易导致自己与别人的代码混成一团。[9]
[github]:
优点：
功能设计简洁实用上手很快，可用性好，已有很多相当质量的各类项目和优秀开发者在上面。[10]
缺点：
1.国内访问速度太慢，经常出现connect time-out；
2.不能很好的解决GB2312/GBK，对中文不够友好；
3.wiki功能太弱，直接导致文档经常被分离到一个独立站点。[11]
[Bitbucket]
优点：
1.支持Hg，最易学易用的分布式版本管理工具；
2.完全免费的闭源项目，还支持5人以内的合作开发；
3.支持中文；
4.官方的git工具SourceTree比GitHub for windows好用。[12]
[Trac]
优点：
Trac做一个SCM配置管理平台，意味着它有良好的扩充性。通过WebAdmin界面中的Plugin功能，可以很方便的安装下载的插件，也可以通过此功能查看已经安装的插件，并可对其中的插件进行启用或停用操作。[13]
[Bugzilla]
优点：
1.强大的检索功能，强大的后端数据库支持, 丰富多样的配置设定等；[14]
2.BugZilla的定制功能的确更强，能满足更多用户差异化的需求。
缺点：
界面比较糟糕。
[Rational]
优点：
提高了团队生产力，在迭代的开发过程、需求管理、基于组建的体系结构、可视化软件建模、验证软件质量及控制软件变更等方面、针对所有关键的开发活动为每个开发成员提供了必要的准则、模版和工具指导，并确保全体成员共享相同的知识基础。它建立了简洁和清晰的过程结构，为开发过程提供较大的通用性。
缺点：
RUP只是一个开发过程，并没有涵盖软件过程的全部内容，例如它缺少关于软件运行和支持等方面的内容，此外，他没有支持多项目的开发结构，这在一定程度上降低了在开发组织内大范围实现重用的可能性。
参考资料：
[1] http://www.xuebuyuan.com/821497.html
[2] https://en.wikipedia.org/wiki/John_Tukey
[3] https://en.wikipedia.org/wiki/Margaret_Hamilton_%28scientist%29
[4] http://kuailiyu.cyzone.cn/article/1453.html
[5] http://digi.163.com/16/0919/06/C1A9M69J001680N8.html
[6] http://www.cnblogs.com/lwl123/p/5253184.html
[7] https://www.zhihu.com/question/20401926/answer/15034642
[8] https://www.zhihu.com/question/21943395
[9] https://www.zhihu.com/question/21905835/answer/94503278
[10] https://www.zhihu.com/question/19591651/answer/12314492
[11] https://www.zhihu.com/question/19591651/answer/12798445
[12] https://www.zhihu.com/question/20053312/answer/20005315
[13] https://baike.baidu.com/item/trac/7367196?fr=aladdin
[14] http://blog.csdn.net/qq_33336155/article/details/53321885