第一次阅读做业

一. 提问

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个电话打不通。这个线路范围内是大银行和证券公司集中的地区，一时间引发了骚乱。

四. 目前流行的源程序版本管理软件和项目管理软件及其优缺点

流行软件：

1. github：约31,000,000用户量
2. SourceForge：约3,700,000用户量
3. Bitbucket：约5,000,000用户量
4. GitLab：约100,000用户量

优缺点：

GitHub

• 优势：GitHub提供Git存储库服务，基于web，容许你使用Git的源代码管理功能及其特性。
• 缺点：可能不是捕捉创意过程和记录创意点子的最佳工具。对于这种特殊功能模拟能够选择LayerVault 或其余类似工具。很是适用代码跟踪，但也响应的保密性较差。

Mercurial

• 优势：有reset，扩展性，append only的存储结构 ，上手简单。
• 缺点：分支管理不灵活。Mercurial的branch管理和Git相比不是很方便。没有命名空间。大型团队不肯使用。

Trac

• 优势：良好的扩充性，很是灵活，能够为所欲为的定制，能够和TortoiseSVN集成。
• 缺点：不支持多项目。需求和缺陷没有分离。核心功能少，不安装插件基本上无法用。

Bugzilla

• 优势：免费且有中文。检索功能强大，有强大的后端数据库支持。
• 缺点：安装须要Perl和配置MySQL数据库，比较繁琐。修改配置文件也很麻烦。流程没法定制。