201571030138 通读《构建之法》一书后的提问-CSDN博客

大二有幸了解过邹欣老师的《构建之法》一书，没想到这学期的软件工程会按照这个模式进行，希望可以在这个学期收获许多工程知识。

问题一

第一章概论

我看了这一段文字：

什么是Bug呢？简单来说，软件的行为和用户的期望值不一样，就叫Bug。是否是Bug，取决于用户、开发者的不同角度。

有一个问题，一是软件的行为和用户的期望值不一样这应该是取决于用户角度，那么从用户角度出现的Bug，在开发者角度来看可能不是一个Bug。这样的情况下显然会出现矛盾，而且需求往往是多变的，我们应该去满足用户的大量需求变更吗？

有这些说法：

1.信息在沟通过程中往往会存在缺失、误解。同样一件事情，不同人理解不同。敏捷开发提供的解决手段是估算：从需求到task，整个团队做估算，争取达到理解一致。

2.外在的场景在不断的发生变化。人往往看到东西才能提出自己的有效反馈。

3.很多时候客户并不知道自己真正的需求是什么。

根据我的实践，我得到这些经验：

跟老师做一个项目的时候，我和另外两个同学负责开发web，我们先是按照客户方的初步需求以及老师的要求，快速的开发出原型。因为web方面的开发只是为了项目后续采集数据，所以客户一直在催工。快要完工的时候，客户提出了新的需求，是之前没有预料到的，导致我们花费了很长的时间去修改。并且之后一直提出一些新的需求，包括技术框架的更改等。通过上面的说法，我能理解到需求是难以确定的。

但是我还是不太懂，我的困惑是这样不停的变更需求，让整个项目的进度推后了好几个月，显然让双方都付出了一些代价。我们应该去满足用户大量的需求变更吗？

问题二

第三章软件工程师的成长

我看到这一段文字：

一个工程师在写程序的时候，经常容易在某一个局部问题上陷进去，花大量时间对其进行优化，无视这个模块对全局的重要性，甚至还不知道这个“全局”是怎么样的。这个毛病早就被归纳为"过早的优化是一切罪恶的根源"。

有一个问题，过早优化显然是没有必要的，但是我们要怎么找到恰当的优化时机呢？

我查了资料，有这些说法：

1.究竟要优化什么？

在优化工作开始的时候，你还尚未明确优化内容和目的，那么你很容易陷入误区。在一开始，你就应该清楚地了解你要达到的效果，以及其他优化相关的各种问题。这些目标需要明确指出（至少精通技术的项目经理可以理解和表达它），接下来，在整个优化过程中，你需要坚持这些目标。

在实际的项目开发中，经常会存在各种各样的变数。可能一开始时要优化这一方面，随后你可能会发现需要优化另一方面。这种情况下，你需要清晰地了解这些变化，并确保团队中的每个人都明白目标已经发生了变化。

2.选择一个正确的优化指标

选择正确的指标，是优化的一个重要组成部分，你需要按照这些指标来测量优化工作的进展情况。如果指标选择不恰当，或者完全错误，你所做的努力有可能白费了。

即使指标正确，也必须有一些辨别。在某些情况下，将最多的努力投入到运行消耗时间最多的那部分代码中，这是实用的策略。但也要记住，Unix/Linux内核的大部分时间花费在了空循环上。

需要注意的是，如果你轻易选择了一个很容易达到的指标，这作用不大，因为没有真正解决问题。你有必要选择一个更复杂的、更接近你的目标的指标。

3.依赖性能分析，而不是直觉

你往往会认为你已经知道哪里需要优化，这是不可取的，尤其是在复杂的软件系统中，性能分析数据应该是第一位的，最后才是直觉。

优化的一个有效的策略是，你要根据所做工作对优化效果的影响来进行排序。在开始工作之前找到影响最大的“路障”，然后再处理小的“路障”。

4.优化不是万金油

优化最重要的规则之一是，你无法优化一切，甚至无法同时优化两个问题。比如，优化了速度，可能会增加资源利用；优化了存储的利用率，可能会使其他地方放慢。你需要权衡一下，哪个更符合你的优化目标

根据我的实践，我得到这些经验：

我们在做一个项目时，后期运行的时候发现java堆内存溢出了，分配了更多的java虚拟机内存后，正常计算出了结果。我们在遇到这个情况之后，进行了优化，将string全部换为了stringbuilder之后，内存占用减少了四分之一。这是我们在出现了问题之后进行了优化，确实取得了不错的结果。

但是在另一个模块的开发中，由于开发经验的不足以及需求不明确，我的模块自己写的代码很混乱，项目快完工了，但是我的代码部分其他人难以理解。我几乎把自己的代码完全重构了一边，幸运的是代码量不是很大。

但是看了上面的说法我还是不太懂，大部分的说法只是说如何进行代码优化，而不会提到代码优化的时机。我的困惑是在项目中，代码优化的时机是什么时候，我们如何确定这个时机？在项目越接近完成的时候再去优化一个大的问题，简直就是灾难。

问题三

第八章需求分析

我看了这一段文字：

另外，很多时候用户并不知道自己确切的需求，或者不愿意表达完整的需求，软件团队需要设身处地，替用户着想，引导出需求。

有一个问题，当用户也不清楚自己确切需求时，我们要如何大概确定用户的需求并引导他们？

我查了资料，有这些说法：

1、需求一定是要解决的，想关掉一扇门，一定要先打开另一扇门。

2、先要确定，这是不是真正的需求。

3、两害相权取其轻，给客户制造冲突。

4、在自身擅长的业务方向上击败需求，用技术说服他。（相对的用关系说服他也是种方式，成本高些）

5、拖住难满足的需求。

根据我的实践，我得到这些经验：

还是同一个项目，我负责开发web中数据管理模块，我们负责项目的老师也同样对我们说要引导对方的需求。但是我们对于这个行业并不是很了解，老师以前也没有接触过这个行业的项目，我们的方式是先做出相关模块，再去引导他们接受。但是越是到后期，他们的需求更改越多。

看了查到的说法，我还是不太懂，当我们不是很了解所做项目所在的行业业务，并且用户本身也不确定需求时，我们要如何快速的发现用户的真实需求？

问题四

第九章项目经理

我看了这一段文字：

产品经理—正确的做产品。

项目经理—正确的做流程。

有一个问题，产品经理要根据市场和用户需求，把握产品定位和方向，而项目经理要保证项目按计划结项。我的理解是当产品经理发现新需求，并更改了原先的方向时，项目经理要去负责团队内部开发流程推动。我感觉这两个职位有重叠的部分，那么产品经理需要了解当前该产品的大概进展吗？

我查了资料，有这些说法：

首先，从知识领域来说，项目经理要求技术背景，这是必须的，一般团队的项目经理由非常有项目经验的RD担当，他的职责在于将目标转化为可量化可实现的项目计划，偏重于执行层面。而产品经理的知识领域较泛，且不一定非要求懂技术。

其次，从责任周期来说，项目经理职责有始有终，他可以负责完一个项目后，再无缝切换到另外一个项目，而产品经理基本不能，产品经理随着产品一同成长，产品的成长更迭伴随着无数的项目。

最后、侧重点不同，项目经理关键词：项目、排期、人月；产品经理关键词：需求、用户、产品。

根据我的实践，我得到这些经验：

我看到过一些产品经理的知识，在实践过程中，当产品经理改变了策略时，项目进度无法跟上时，就会导致产品无法按时交付吧。看到的说法大都是讲产品经理和项目经理之间的区别。

我还是很困惑，产品经理不需要掌握一些产品当前流程吗？