第一次阅读作业
一. 提问
1.第四章 代码设计规范
“函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto。。。”
老生常谈而且也难以定论的东西：goto的简便和难以被完全替代的作用确实受到一部分人喜爱，可也存在容易导致代码可读性下降难以维护，破坏结构化设计风格，或者因使用不当造成错误和隐患。
2.第四章 结对编程
“他们并排坐在一台电脑前，面对同一个显示器，使用同一个键盘，同一个鼠标一起工作。他们一起分析，一起设计，一起写测试样例，一起编码，一起做单元测试，一起做集成测试，一起写文档。。。”
也许是编程经验不够丰富，个人阅历不足，总觉得完全地“二人合体”编程并不是一个很有效率的办法。两人合作感觉不必那么长时间的接近。交流固然重要，但要两个人挤在同一张桌子前面，四只手两个头去分享两三平米空间上的同一副键鼠，难道不会碍手碍脚吗？也许这其中有个人的性格原因，不过也许也只是上面这段文字只是作者的一个说笑似的打比方。
3.第十六章 创新和作坊
“有管理专家建议，在工作需要的人数基础再减掉一位，这才是最优的数字”
当n-1人是成为最优的团队人数时，就要又有一位牺牲者出现，n-2的团队稳定下来之后又要减掉一位。。。这种不把劳动力当人使的资本主义思想我觉得是万万要不得的。。。（没有买卖就没有杀害）
4.第一章 软件=程序+软件工程
“如果一架民用飞机上有需求，用户使用它的概率是百万分之一，你还要做这个功能么？”
第一堂课上就提了这个问题。不过老师先说的是软件功能百万分之一概率使用，后来又提出飞机。。。老实说飞机和软件还是不能完全互相比较的。飞机缺失某项重要功能导致的几乎全是悲剧，但软件缺失某功能也许并不会有巨大的影响。再从影响的大小来看，飞机一旦失事基本不会留活口，软件出了问题或者某个功能没实现大概就是被使用者骂，骂完再骂到写代码的头上。。。这种完全不同量级的问题放在一起比较是狡猾的。
5.第九章 项目经理
“PM做开发和测试之外的所有事情”
“五彩斑斓的黑”之类已经玩烂了。一个完全不去开发的PM难以了解一些项目的难点，然后就异想天开的提出看似美妙实际天女散花的要求。就想某位大佬博客中写的一个有趣的故事：PM要程序员做一个能根据手机套改变手机主题颜色的小程序。在PM看来，你们都能让抢票软件24小时抢票，让手机主题变个色当然也不是难事，可是在实现者面前第一个问题就是你怎么知道手机套的颜色？靠爱肯定是不行的，难道让摄像头自己探出来看看手机套再把颜色传回来（？），当然有个类似的例子是坚果一代手机的手机背壳上都带有一块小芯片，不同背壳安装后（其实就是不同芯片）就能让手机识别到，询问用户是否要更改对应的主题颜色（不用换背壳也能换主题，但是老罗就喜欢这些花里胡哨的（？））。
二. 请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？
- 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.（最早在工程背景下出版的术语“软件”是由Richard R. Carhart在兰德公司研究备忘录中于1953年8月出版的。）
- Margaret H. Hamilton began to use the term "software engineering" during the early Apollo missions in order to give software the legitimacy of other fields such as hardware engineering.（在早期的阿波罗任务中，玛格丽特·汉密尔顿开始使用“软件工程”这个术语，以使软件具有硬件工程等其他领域的合法性。）
三. 软件工程发展的过程中有趣的冷知识和故事？
“故障与社会恐慌”
- 日本的D10电话系统的故障曾引起轰动。1980年10月，日本神户元町电话局D10系统发生故障，使得确保市民安全匪警及火警紧急电话线路中断长达9个小时，整个城市的公民们处在极度的恐怖状态之中。第二年的3月，东京霞关电话局的D10系统也发生了故障。从国会打不出电话足有50分钟，国家政治中枢陷入完全麻痹的窘境。在1981年3月，关西地区经济中心，大阪北滨电话局的D10系统也出现了故障。大约在50分钟内，约有8000个电话打不通。这个线路范围内是大银行和证券公司集中的地区，一时间引起了骚乱。
四. 目前流行的源程序版本管理软件和项目管理软件及其优缺点
流行软件：
- github：约31,000,000用户量
- SourceForge：约3,700,000用户量
- Bitbucket：约5,000,000用户量
- GitLab：约100,000用户量
优缺点：
GitHub
- 优点：GitHub提供Git存储库服务，基于web，允许你使用Git的源代码管理功能及其特性。
- 缺点：可能不是捕捉创意过程和记录创意点子的最佳工具。对于这种特殊功能模拟可以选择LayerVault 或其他相似工具。非常适用代码跟踪，但也响应的保密性较差。
Mercurial
- 优点：有reset，扩展性，append only的存储结构 ，上手简单。
- 缺点：分支管理不灵活。Mercurial的branch管理和Git相比不是很方便。没有命名空间。大型团队不愿使用。
Trac
- 优点：良好的扩充性，非常灵活，可以随心所欲的定制，可以和TortoiseSVN集成。
- 缺点：不支持多项目。需求和缺陷没有分离。核心功能少，不安装插件基本上没法用。
Bugzilla
- 优点：免费且有中文。检索功能强大，有强大的后端数据库支持。
- 缺点：安装需要Perl和配置MySQL数据库，比较繁琐。修改配置文件也很麻烦。流程无法定制。
