第一周博客作业（二）

我看书速度比较慢，编程经验不多，目前看了《构建之法》前七章还有9、16章，前7章感觉偏理论一点理解起来有些难度，我想是因为我看的书太少了，尤其是计算机类的书籍。所以下面的问题感觉也都是一些直接经验或观点。请读者见谅。

1.回答65页4.的问题。这个问题是程序员想用自己独特的方法解决问题并取得老板同意，但是在ddl接近之时发现方案漏洞，此时他应该怎么办。我认为他应该马上和领导报告此事，让领导掌握项目的进展和问题，以便于领导安排，应对风险，尽量把损失降到最低。这个到底怎么做会是比较好的呢？

2.结对编程，85页中解释了什么是结对编程并且说明了大多数人有的疑问。我之前按照字面理解结对编程是两个人合作分工做项目然后整合到一起，但是看了书中的解释是一个人写代码一个人看代码，然后轮换。很大的问题是效率问题，我感觉这对我来讲是比较大的挑战，一是因为我代码行数少，但是如果能看到比较厉害的学长学姐写代码似乎也能学习到很多，但是别人看我写代码感觉……不知道怎么说好，尴尬吧。

3.书16.4节直到376页，本节末尾说：“很多同学热衷于技术和技术的创新，但是当大家在埋头搞技术时，是否注意到自己是在用屁股对着目标用户？” 这个关于魔方的创新故事，结尾二柱同学的创新，应该是作者想要表达的创新并且针对目标用户女生们。但是，还有一种说法是用户并不知道自己要什么，而是生产者设计者生产出一种产品，他们才知道自己需不需要。故事中的女生们大多不喜欢自己玩魔方，只是喜欢看男生们玩得很6，后来二柱给魔方包装一下，换上女生们喜欢的图案，她们觉得好看才喜欢掏钱买。我想作者是想说开发者要对用户足够了解然后设计开发，但是事实是女生只是喜欢好看的图案包装，并不喜欢魔方，换一个载体比如好看的本子、贴纸，都会得到女生用户。那魔方的价值是什么呢？

4.书378页中说到团队大小的问题，“小即是美”，说管理专家建议在工作需要的人数基础再减掉一位，才是最优的数字。然后我设想了一个问题：如果团队人数多了要怎么办呢？有一种情况是本来认为项目着急任务也不少，需要很多人手，结果做起来发现，模块分一分每个人的工作量也不大，后来几乎完成了，但是项目又不着急了，可是还有一堆bug没人测试，没人修改。

5.还有一个假设的问题：在公司中，如果一个团队，PM安排了比较明确的分工，A做A模块，B做B模块，把项目基本做出来了，但是A的模块存在bug，B的模块几乎没有bug，B是可以置之不理，感觉自己圆满没事了可以跟老板交任务了走人了，还是也需要做项目测试其他模块并debug呢？我认为他是需要做A的任务的，那这是出于义务还是责任呢？A如果遇到改不了的bug改怎么办呢？A会有什么后果？

（字数1047）