【软件工程】第1次阅读作业

项目	内容
课程	软件工程(罗杰)
作业要求	第1次阅读作业
本次作业要完成的目标	阅读《构建之法》，快速了解软件工程的相关知识和过程并提出疑问

快速看完整部教材，列出你仍然不懂的问题

问题1 对于小概率使用的需求，究竟要不要做

说到商用软件和爱好者写的程序的区别，我们还可以看看这个例子：
如果一架民用飞机上有需求，用户使用它的概率是百万分之一，你还要做这个功能么？
-- 来自第一章，p6

书上的例子是飞机的安全功能，选择是不但要做，还要不厌其烦地告诉用户如何使用。我认为这里的例子不合适，在商用软件这个问题上，民用飞机是个相当特殊的例子，其安全性关乎一整个飞机的人的性命，而它出安全问题的概率很低，这里正好符合劝诫同学们对于小概率使用的需求也要做并告诉用户的理念。

并不是说这个理念不好，而是对于多数商品，为了完成小概率使用的那些需求有时候需要的投入过高或者会使收益降低，也就是说是个亏本买卖。在广泛的商用软件这个话题上，商用也意味着市场和商机，有的时候发布时间意味着这一代产品能否为自己带来足够的利益，对于有些没时间实现的功能，有时候放弃也是可以的。再者，既然是软件工程这个课题的事，我们的产品也不是一锤子买卖，而是有后续更新的，这些问题完全可以留到后续更新时修复或者添加。比如前些天华为和三星都公布了折叠屏手机，要是过两天哪个厂也来公布一下折叠屏手机，又没有很大的足够吸引人的突破，那可以想象这个后公布的厂家在竞争上很可能会弱势一些。当然像之前三星某型号爆炸那样的致命(物理意义)问题要是能发现可不能因为时间不够就算了

综上，我认为对于需求，不应该把所有问题一概而论，我们确实对于任何安全问题不能有丝毫放松，但把安全问题和其他无关痛痒的小需求相提并论是是不现实的。

问题2 goto语句

函数最好有单一的出口，为了达到这一目的，可以使用goto
--来自第4章，p69

书上之后一句是“只要有助于程序逻辑的清晰体现，什么方法都可以用，包括goto”，我认为还是要减少goto使用。从我进入大学开始接触编程开始，到看到这本书之前，所有老师都说不要用goto或者至少是尽量不用goto，我认为goto本身确实没错，为了解决问题，goto的逻辑相当清晰，甚至用到之前的课里也会没问题，就像本课调侃的“之前的课也许就是面向一个老师，过了就万事大吉”，那样的话用用goto可能相当方便(虽然没试过)。但是软件工程不是一遍就完了的，goto还会在后续版本迭代中修改时对整体阅读、更改甚至平台移植等等都有可能造成额外的工作量，我认为在工程中应当减少goto，不应该为了在一个版本中为了逻辑清晰而对透支后续工作。

结对编程

问题3 结对编程的好处

如果运用得当，结对编程可以取得更高的投入产出比。
--来自第4章，p80

这里提到了很多结对编程的好处，在课程中也有结对项目，而且作为同学也方便交流沟通，确实问题不大，我的疑问是在今后的开发过程中结对编程是否具有实效意义。毕竟现在开发多为团队开发，有更多的人可以从中调节，而结对是一对一的，如同书上后文所述，结对的阶段从萌芽、磨合、规范到创造是理想的，但也有解体这种可能性。虽然成功的案例有不少，而且还是巨大成功（苹果、谷歌等），但是失败总是不为人知的不是吗。

问题4 结对编程的形式

他们并排坐在一台电脑前，面对同一个显示器，使用同一个键盘、同一个鼠标一起工作。他们一起分析，一起设计，一起写测试用例，一起编码，一起做单元测试，一起做集成测试，一起写文档，等等。
--来自第4章，p79

我以为结对编程是两个人写自己的东西，写好接口之类，然后两份代码合起来就成了，大概就是团队的模式，只不过是二人小团队而已。而上文所述是否过于苛刻？后文有述“因为有随时的复审和交流，程序各方面的质量取决于一对程序员中各方面较高的那一位”，那这对于低水平那一位确实很好，但对高水平那一位有什么提升呢？进一步，对于两方水平都不算高那陷入困境会不会对双方造成很大的消耗（当然，如果能攻克，攻克之后的提升也会很大），或者对于两方水平都比较高，但是理解不同，这种方式会不会容易使双方造成分歧从而降低效率？

问题5 用户体验

在第12章有相当多的描述，不一一引用，我的疑问是用户体验的影响到底是何种程度的？

书上有一个用户体验与产品质量冲突的例子，讲GE总裁杰克韦尔奇的故事，说是核磁共振机通道狭窄令病人不舒服，但是为了扫描质量GE公司的专家没能牺牲成像质量换用户体验，而对手推出宽通道设备后GE公司用了2年才赶上。这里用户体验的影响可以说是决定性的。

另一个例子，win10用户体验计划把系统弄慢，因此很多用户选择关闭这个功能，这可以说是因为这个项目的用户体验不佳，但是因此用户放弃了提供数据获得之后版本的更优质的体验，这个问题怎么看待？

“软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人

软件
最早在工程背景下出版的术语“软件”是由Richard R. Carhart在兰德公司研究备忘录中于1953年8月出版的。

软件工程
1968 年北大西洋公约组织在前联邦德国开会提出的。
1968年秋季，NATO（北约）的科技委员会召集了近50名一流的编程人员、计算机科学家和工业界巨头，讨论和制定摆脱“软件危机”的对策。在那次会议上第一次提出了软件工程（software engineering）这个概念。

大家知道了软件和软件工程的起源，请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事？

软件工程发展到现在也能算是发展过程中吧，那些老故事就不复述了，说一个前几天看到了趣事，来自微博@TimYang

“马化腾提议：代码缩进要用3个空格。 ​​​​”

在本书第4章也有提到代码风格的问题，书上原文是

是用Tab键好，还是2、4、8个空格?
结论：4个空格······
--来自第4章，p64

这里甚至没有提到3个空格这个说法，本来我打算写在第一部分算个问题的，后来想想这个事该放在这里才对。

上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？

截图自维基百科

• Microsoft TFS

  • 优点

    • 对敏捷，msf，cmmi等项目、过程管理、过程改善的支持。任务版上能将需求、项目进度一览无余，对于小团队而言，比甘特图更有用。

  • 缺点

    • 能应用起来的团队、公司的数量极少，多数真正用起来，也就是源代码管理这部分，这也仅仅是占TFS极小部分功能。

• GitHub

  • 优点

    • GitHub提供Git存储库服务，基于web，允许你使用Git的源代码管理功能，或者其特性。GitHub提供Git存储库服务，基于web，允许你使用Git的源代码管理功能，或者其特性。

  • 缺点

    • 可能不是捕捉创意过程和记录创意点子的最佳工具。对于这种特殊功能模拟可以选择LayerVault 或其他相似工具。之前，我们已经强调过Github非常适用代码跟踪，但是却不是最好的设计跟踪工具。将图片内容转化为代码，或者将设计用于产品设置，看起来依旧不是那样顺利。

• Trac

  • 优点

    • 非常灵活，可以随心所欲控制可以和SVN集成

  • 缺点

    • 功能不是很强大

• Bugzilla

  • 优点

    • 免费，有中文版支持

  • 缺点

    • 快速搜索结果不准确。只能管理缺陷。

• Apple XCode

  • 优点：编译速度极快，每次操作都很快速和轻松。自动提供撤消、重做和保存功能，无需编写任何编码。

  • 缺点：更新版本后，某个插件可能会失效。

来自目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？