标签：工程 ret nbsp 场景 语句 步骤 情况 流程 基础
第一堂课上老师就要求我们在一个周内看完课本，然后提出自己不懂的地方。用了一周的时间，我大概读完了这本书，以下是我在这本书中所遇到的不解之处：
1、在书的第二章《个人技术和流程》中，有这样一段文字：软件实体应该是可以扩展的，同时是不可修改的。当时的疑惑是怎么才能做到可以扩展但是又不可修改，然后看了下面给出的解释是说当需求发生变化时，我们可以对模块进行扩展，从而来改变模块的功能；但是对模块进行扩展时，不必改变模块的本身。这确实是一个可以实现的办法，但是就实际的实践来说，当新的需求出现的时候，我们是否就一定能保证能在之前模块的基础上并且不修改模块本身来实现新的需求呢？如果新的需求确实需要修改模块本省才能达到，那么我们会如何进行选择，实现需求还是保持模块本身？那么模块的不可修改又是否是绝对的？
2、在第三章《软件工程师的成长》中，有一个小标题是“专和精的关系”，但是却没有具体的花篇幅来详细阐述这两者的关系，而是通过列举单人乐队和乐手的例子来说明的。看到这个标题的第一反应是，专和精好像没有什么区别。看完书上列举的例子，总结一下大概就是说，单人乐队什么都会，此为专；而乐手只研习某一种乐器，此为精。但对这两者的却别还是很疑惑，上网百度了一下也没有找到关于这一问题的具体说明。我疑惑的是：我理解的“专”是对某一技能的专研，那么单人乐队什么都会，如何能称为专呢？再者，“专”和“精”区别的标准是什么，“专”的范围中是否能包含“精”呢？
3、在第四章《两人合作》中，代码规范设计子单元下，有提到为了使函数有单一的出口，可以使用goto。goto，第一次接触到这个语句，看了下面给的代码清单，觉着你用法有点类似于我经常用的return，带着对这个语句的好奇，我上网找了一些资料来了解这个语句的功能及用法，其解释为goto语句也称为无条件转移语句，其一般格式如下：goto语句标号；其中语句标号是按标识符规定书写的符号，放在某一语句行的前面，标号后加冒号(：)。语句标号起标识语句的作用，与goto语句配合使用。如：label:i++;loop:while(x<7);goto语句的语义是改变程序流向，转去执行语句标号所标识的语句。goto语句通常与条件语句配合使用。可用来实现条件转移，构成循环，跳出循环体等功能。但是，在结构化程序设计中一般不主张使用goto语句，以免造成程序流程的混乱，使理解和调试程序都产生困难。看完后大概了解了goto语句，但是网上大部分的建议都说一般不建议使用goto语句，而教材中却单独提出来了，那么什么情况下会倾向于使用goto语句呢？既然goto语句有缺陷，又是否有另一种与之功能相同且进一步优化后的语句存在呢？
4、在第四章《两人合作》中提到结对编程，其中有一段文字这样提到：结对编程是一个不断复审的过程，且列举了结对编程与传统开发过的复审的区别。结对编程，顾名思义是一对程序员肩并肩，平等的，互补的进行开发工作，在此过程中，两人所写的代码处于不断的复审中，我的疑问是，结对编程完成的代码是否还需要经过团队的进一步复审呢？如果不再进行团队复审，那么在结对编程的过程中并如何能保证两人能完全解决发现的问题，或者发现其他潜在的问题？如果还要经过团队复审的话，那么之前对比的其存在的那些不足还是依然存在，就软件开发的效率来说的话，结对编程就并没有体现出多大的优势来。
5、在第六章《敏捷流程》中，有详细介绍到采用敏捷流程编程的具体的步骤，其中第三步是冲刺，在这个阶段，团队每日会通过每日立会来面对面的交流，大家依次报告的内容为：我昨天做了啥？我今天要做啥？我碰到了哪些问题？那么报告完这些问题以后又怎么处理呢，加入团队中的某一个人昨天遇到的问题，自己不能解决，是今天继续解决还是分配给团队其他人解决？在第七章《实战中的软件工程》中，重点讲解的是MSF的9条基本原则，其中第8条是学习所有的经验。而教材上讲到是通过在完成每一个里程碑后都要做一个“里程碑”回顾，这里的回顾跟每日立会有什么异同呢？哪一种又更具优势呢？在第七章后面又提到，到了2015年左右，微软的所有小团队都采用敏捷流程，是否说明每日立会更具价值呢？
6、关于断言，在错误处理中，如何验证错误性，就需要用到断言，教材上的原文是：当你觉得某事肯定如何时，就可以用到断言。如果认为某事可能会发生，就需要写代码来处理可能发生的错误情况。我的疑问是：断言的标准是什么，就仅仅是个人认为吗？如果个人认为并不准确呢？本来有可能发生的事却用了断言，那么又会对程序产生怎么样的影响呢？
7、在第十章《典型用户和场景》中，讲到怎样定义典型用户，其中有一段文字是这样说的：除了进一步了解用户的需求，细化了一些功能的设想外，我们还发现，我们的第一个典型用户，吴石头，好像不喜欢上网，他事实上不太会用电脑，凡是和网络有关的事都交给了他的儿子，所以不得不把吴石头从典型用户中删除。这一步是在细化典型用户，细化典型用户的具体标准是什么？在去除典型用户以后，他所代表的典型场景是否也随之删除？若删除那么需要该典型场景时怎么解决？若不删除又应如何处理？
以上是我大概阅读教材所遇到的问题，不深入也不具有代表性，但既然有问题存在就应该去解决，所以我会在以后的深入学习和实践中去寻找答案。
标签：工程 ret nbsp 场景 语句 步骤 情况 流程 基础
原文地址：http://www.cnblogs.com/fancy-dawning/p/7514266.html
