Ch09

移山方法论中需要在大致了解需求、详细了解需求、了解测试需求和了解高级需求后分别对完成该项目的时间进行估值。那么，是在每一个阶段都拿出一个能运行的成品还是在完成上述所有估值之后在进行代码的编写？

个人感觉每一次估值似乎都对应着MSF中过程模型的一个周期。但是对于一个团队来说，有些需求或其他的了解和估值似乎是可以同步进行的，且在完全了解了各种需求后可以减少迭代次数，缩短开发周期（缺点是每一次迭代的任务有些重）。那么如何在二者间做出权衡？

自顶向下从客户需求出发和自底向上从已有研究和初步结果出发是两个不同的方式，能否详细的介绍一下？若二者得出的结论有较大分歧的话，是应该优先满足自顶向下得到的功能需求还是自底向上搭建的功能，还是二者都要满足？

因为在文中只有寥寥几行，但是我还是想了解的更多一些，所以有此一问。此外，就我个人感觉自顶向下与自底向上分析很有可能出现分歧（因为角度不一样），所以我们是要面对这种分歧并进行一定的选择，还是干脆只进行自顶向下或自底向上的分析？

在团队项目中，成员需要对每一个功能模块都进行效能分析吗？还是由专门的人员从整体进行效能分析？

提出这个问题的原因是我往往不知道我所写的模块在整个系统中被调用的频率，如果我的模块被调用的频率较低而我却花费了大量的时间对其进行优化，则会直接提高项目开发的成本。这是否也要求团队中的每一个成员都需要对项目有大局观？

320

P157：（第三段和末段）这是场景，也可以叫任务……；因此，“场景”可以等同于“任务”。

问：场景和任务有什么不同的地方？

P159：（9.3.1）工作的划分和WBS

问：下文没有提及WBS，WBS指的是什么？

P163：（末段）第一步，要确保编译的程序时Release版本。

问：为什么要用release版本，以及第一次取棋子的作业也要用release版本的提交，release和debug版本有什么不同用处？

P164：（第二段末尾句）注入的代码也影响了程序的真实运行情况。

问：代码注入测得的结果是函数的调用次数，而非时间，那么注入代码会影响到测量结果的真实性么？

319

P159：9.3.1工作的划分和WBS

什么是WBS？

119

在书的第九章最后讲到了效能分析，但是没有讲资源分析（也就是程序的内存开销），是不是说在现在这个空间资源相对较为丰富的环境下，效率才是软件的最为看重的performance，而原来的一些同时注重空间利用的思想（我们汇编老师曾给我们讲过他们竭尽心血节省寄存器的历史）就不重要了呢？是不是就可以拿空间换时间呢？在什么时候可以这样，什么时候又不可以呢？

在看代码规范的时候想到的：我们写程序的时候是不是应该尽量用一些由语言封装好的数据结构还有函数呢？是不是一般语言封装的会有更好的效率呢？（比方说我自己写struct和利用C++提供的标准结构）

117

有时候对于手动的效能的分析，不能做到准确，因为有些奇异的测试样例是很难构造出来的，在这种情况下，如何测试程序的效能？VSTS的效能分析工具能起到作用吗？

现代软件，真的一点空间效率也不需要考虑吗？显然不是吧……对于一些大型软件，如何去平衡空间和时间的问题呢？

Ch10

415

程序中要尽量添加多的注释么？注释都要很详细的介绍函数的功能么？

需要什么样的人来做代码复审？如果是对这个阶段代码很熟的人的话，那最熟的不就是写这段代码的人么，如果有更熟的人或者对这部分开发更了解的人为什么部直接找那个复审的人开发就可以了？复审人员和测试人员可以叠加么？

一段代码在复审之后，这段代码是不是就可以确定了，也就是说在以后的开发过程中无需再重看这段代码？

412

需要代码复审的时候，代码覆盖率大概应该到什么程度？如果这样的话，基本的代码错误已经是可以避免了吧。那么代码复审主要针对的是哪方面呢？

我听说很多公司都会有它内部的一套代码规范，一套命名规则，那么书中提到的代码规范是不是针对于那些自由编程者，作为他们交流的规范呢？那么如果这样的话对于自由编程者是没有什么强制力的，又怎么能保证大家比较严格的按照规范走呢？

406

一个团队的代码规范应该细化到什么粒度？

本章的问题比较少，但并不表示我全明白。之所以提出这个问题是因为但就我们学生团队来说，大家编程时一般都各自为战，编码风格迥异。但是有些诸如大括号的位置一类的无伤大雅的风格不同的成员可能会有不同的选择（如另起一行，或直接写在后面）。若是对这些做硬性规定有可能会影响到程序员的编码效率和心情（感觉写代码写的不顺手了）。那么是不是可以在团队内成员都理解的情况下，放开一部分的代码规范，使其能兼顾程序员的编码习惯和对内其他成员对其的理解？

代码复审的某些部分与软件测试很像，可否把代码复审集成到软件测试中？

比如说，单元测试有点像自我复审；伙伴测试又有点像同伴复审。那么，把他们进行合并是不是一种不错的想法呢？或者说在移山方法中本来就是这样做的？

323

P171 统一代码风格一章。

统一代码风格对于一个软件工程来说是必不可少的一部分，那么是否应该把代码风格放在最重要的位置呢？不同的人会有不同的编程习惯，不同的编程语言也有不成文的风格规定，如果一个人用惯了某一种编程风格，那么改变风格可能会对一些优秀而怪异的人才来说是很难办到的，这时候我们应该怎么做？

P179  “异常不能跨过DLL或进程边界来传递信息”。

那么我们可以把异常保存起来再进行传递呢？只是不知道这样做有没有意义。

320

P173：（10.1.5）更严格的说，不要把不同的变量第一在一行上。

问：为什么要这样（我好像一直都定义在一行上），除了多出几行必要性在哪？

P174：（10.1.6末段）在这样的语句中，前缀就不是很必要的，匈牙利命名法则不适用了。

问：即使在这种情况下，匈牙利命名法照样可以提高程序的可读性，问什么不适用了？

P175：（10.1.9倒数第二段）注释应只用ASCII字符，不要用中文或其他特殊字符，它们会极大的影响程序的可移植性。

问：程序里的注释在编译时会忽略掉，为什么还会影响可移植性，是影响移植后程序的可读性么？

P177：（1.参数处理）在Debug版本中，所有的参数都要验证其正确性。在正式版本中，从外部传递过来的参数都要验证其正确性。

问：release版本的需要验证么，从外部传递来的参数的正确性怎么验证？

P179：（8（2））New不一定都成功。

问：什么情况会导致New失败？

P182：（首段）编译要用团队规定的最严格的编译警告等级。

问：这个等级怎么设置，在哪设置？

319

P180：10.3 代码复审

如何安排代码复审的时间、频率最好？

117

有时候当一个人形成固定的代码风格后，是很难改变的，这时候，让两个人去合作完成，是同一风格好呢？还是各自用各自的好呢？我觉得统一风格的劣势是在将来的某一天，改变风格的那个人很有可能看不懂自己之前写的代码，不统一的劣势是，别人看程序会感觉很乱。

为什么goto语句如果方便的话，能否使用其在两个人分别写的代码之间跳？这样的危险性大吗？需要绝对禁止吗？

代码复审工作的效率有多高？一般代码复审几次、什么状态可以保证其质量？有方法可以使代码复审的效率提高吗？比如说对于一些出错概率低的代码不进行复审（我自己的想法）。

Ch11

406

在结对编程中如何评价二人的贡献？

由于关于两人合作的部分在课上讲过，所以没有太多问题。我的意思是，如何判断驾驶员和领航员都正确的发挥了各自的作用？是不是因为有领航员在，间接提高了驾驶员的注意力，从而提高了代码的质量，从而即使领航员在一旁一言不发，他（她）也算是发挥了作用？或者是领航员必须在一旁指指点点，喋喋不休，才算正确发挥了作用？

323

P190 小慧的一段话。

我们在做项目的时候，从来都是自己当自己的客户来分析自己设计的呀！学校里的很多理论我们以后可能都不会再用到，但是思想应该是最重要的吧？真正的东西要到现实世界里去体验！

P190 阿超所说的一段话。

这跟我们学习的过程是一样的呀！ 都是从易到难，要想成为一个领域里面的栋梁之才，需要时间慢慢修炼呀！不能急功近利！

P202 “随机数增加测试的真实性”。

我们可以先把系统生成的随机数保存起来，如果出了错误，我们再去找出来不就可以重现了吗?这样既增加了真实性，有减少了测试人员的负担，一举两得的事情为什么不干呢?

P208 极致编程“每时每刻都有客户在身边”。

这好像做到有很大的困难呀！首先客户必须派一个能做得了主的人，那么这个人对于客户一方来说肯定是一个很重要的人，将一个这么重要的人放到这样的地方，客户会愿意吗？再加上人家也不能整天有事没事的坐在那等待别人问问题吧，这不把人家给烦死了才怪呢！另一方面，这个客户代表是在为谁工作？哪一方应该付给他工资呢？

P208 “别做详细的设计”

不做详细的设计，那就是意味着，每一次变化需求都应该得到响应，这种变化无常的状态什么时候是一个头呢？

P215 “优点和缺点的比例要达到3：1”。

为什么是3：1， 有什么根据吗？

320

（表格）那就别做详细的设计，做频繁的增量开发，重构和频繁的发布。

问：没有详细的计划的话，会不会做到一半的时候就不知道下步该怎么做了，或者找不到方向。

319

P201：11.5好的单元测试的标准 第二条 单元测试必须有最熟悉代码的人（程序的作者）来写

单元测试由程序作者来写，有其他人写不会更好的发现程序作者自己意识不到的问题吗？

P211：11.8 两人的合作——如何影响对方

二人合作碰到不同意见怎么办？书上说的太笼统。

119

在十一章第五节中讨论了好的单元测试的标准，其中有一条写到“单元测试必须有最熟悉代码的人（程序的作者）来写”。但是程序的作者在写单元测试时会不会受到自己写程序的时候的思想所影响呢？导致有的bug隐藏不被发现出来。

书第206页说到了“牛仔式编程”，什么是“牛仔式编程”？是不是指个人主义式的编程？

117

对于好的单元测试标准，我有一个疑问。对于规模不同的系统或者复杂度大小不同的的功能进行测试，使用的单元测试的规模应该是不同的吧（对于简单的诸如测试加法的功能，不需要太多的测试用例，数据也不需要太偏，但是对于类似word,杀毒软件这种大的软件系统，测试用例显然不能太简单）。但是究竟什么样规模的系统，或者什么样复杂度的功能应该采取什么样复杂的测试用例呢？