粗略翻看了《构建之法》这本书后，提出了5个有关的、无关的问题，或许有的很幼稚，但恕我愚笨，理解的不够透彻，故此提出，希望老师同学可以予以解答，最好是通俗易懂的案例.
1、代码复审时，修改了当前问题，但是导致另一潜在问题出现，当潜在问题修改后，又会出现另一个问题，因为修改当前问题而引起新的问题，这种情况该如何解决？？是推到重写还是将就使用？？
2、在项目或者团队工作时，我们的程序写来是要给计算机编译，但是主要还是让“旁观者”看清，这样他才会愿意接手这段代码，所以，代码规范就相当重要。依据代码规范，我们需要给代码添加注释，但是怎么添加注释？需要注释什么？
答案：不要注释程序是怎么工作的，你的程序本身就应该能说明这一问题。
//this loop starts the i form 0 to len,in each step,it does SomeThing
for(i=0;i<len;i++)
{
DosomeThing();
}
以上注释就是多余的。
注释是用来解释程序做什么（What），为什么这样做（Why），以及特备别注意的地方的，如下：
//go thru the array,note the last element is at [len-1]
for(i=0;i<len;i++)
{
DosomeThing();
}
复杂的注释应该放在函数头，很多函数头的注释都是解释参数的类型等的，如果程序正文已经能够说明参数的类型等，就不要重复。
以上是我找到的答案，但是我还是觉得不够严谨，对于注释添加在哪个位置就是合适的注释，是有一定的规范吗？还是凭个人喜好？依然心存疑虑。
3、很多新入职的程序员在维护系统时会觉得之前的人写的程序不够理想，所以经常会有人想推倒重来，但是他心在看到的程序代码，已经是他之前的人推倒重写过的，而其他同事在使用时觉得还不如第一个人写的好用，这时，新职员是该推倒重写呢？还是继续维护之前的人写的系统？毕竟推倒重写不仅工作量大，还要考虑其他同事的意见，但是不推倒重来，我觉得对于一个编程高手是一件很难受的事，那么，怎么在这两者之间找到平衡之法呢？
4、MSF强调产品团队与顾客的交流与合作，并不是拿到合同之后就闭门造车，因为项目的商业价值要由用户说了算，那么跟用户沟通就是重头戏，但是有时候由于用户不懂他想要的是什么，或者用户想要的和商业价值无关，又或者用户想要的我们还不懂，等等，各种问题，产品团队无法有效的了解用户的需求，那么如何跟用户进行高效、准确的需求沟通就成了一个迫在眉睫的问题。
答案：a.访谈
b.现场考察
c.资料查阅
d.问卷调查
e.市场调研/竞品分析
以上是在网上找的答案，可是因为没有实践的缘故，理解的不是很透彻。
5、软件工程师往往以熟练掌握认知阻力大的工具而自豪，但是大多数用户的心理是要躲避认知阻力。IT产品的用户，有些是喜欢高科技的，喜欢尝试新的交互方式和体验，所以它们对认知阻力大一点的工具很有兴趣；大部分还是依赖于传统和系统提供的指令来交互，他们希望IT系统升级之后，还是熟悉的界面，东西还是在原来的地方。那么，软件工程师在设计软件时是一味的附和大多数人的习惯，还是只考虑喜欢高科技的人群的需求，又或者两者兼得？如果两者兼得，那么为了少数人而增加一倍的工作量，是否划算？