第四章：
问题一：第66页，关于goto语句的使用。书中介绍了goto语句，并阐释它的作用为让函数具有单一的出口。而在我的认知里，goto语句是极力避免的。
为什么说要极力避免goto语句，它有不少好处，它可以不受限制的灵活跳转，但是正是因为这个强大的功能，程序员在使用goto语句的时候就很容易因为跳转而略过了一些关键语句。
比如：
goto state；
String s1,s2; //被goto跳过
int sum = 0； //被goto跳过
......
.....
state：
如果编译器不能发现此类错误，每用一次goto语句都可能留下隐患。
还比如：
你正在阅读上千行的代码，但读到一千行的时候晕头转向的，不明白程序中出现的一些子程序什么意思，知道读到最后看到了goto语句，然后再愤怒地跳回去一遍一遍看。可见，非常降低代码的可读性。
G·加科皮尼和C·波姆从理论上证明了：任何程序都可以用顺序、分支和重复结构表示出来。这个结论表明，从高级程序语言中去掉GOTO语句并不影响高级程序语言的编程能力，而且编写的程序的结构更加清晰。所以，我们完全不必用goto语句，任何需要goto语句的地方我们也可以用其它语句代替，并营造出更好的程序逻辑。不然，着会增加后期代码维护的复杂度。因为真正的项目不是你单枪匹马的做出来的，你需要和其他人合作。所以写出的代码应该是简单易懂，容易维护的。
问题二：
P75页的结对编程，它列举了很多好处。1，在开发层次，结对编程能提供更好的设计质量和代码质量，两人合作解决问题的能力更强。2，对开发人员自身来说，结对工作能带来更多的信心，高质量的产出能带来更高的满足感。3，在企业管理层次上，结对能更有效的交流，相互学习和传递经验，分享知识，能更好地应对人员流动。总之如果运用得当，结对编程可以取得更高的投入产出比。
在我眼里，它是理想化的编程方式，落实非常困难。它有很多缺点：
1、与合不来的人一起编程容易发生争执，不利于团队和谐。
2、经验丰富的老手可能会对新手产生不满的情绪。
3、一山不容二虎，开发者之间可能就某一问题发生分歧，产生矛盾，造成不必要的内耗。
4、开发人员可能会在工作时交谈一些与工作无关的事，分散注意力，造成效率低下。
等等……
试想，在某一个学习环境，或者工作环境，和自己水平相当的人大概在20%里，假设环境有一百人，你也就在20人内挑选，你要在着20人里挑选伙伴。结对编程是一种非常亲密的工作关系，如果你有对象，你是不是应该为了避嫌最好找同性，这一下减少一半，只剩10个人，在着10个人里找到还没有合作关系的人，又要减少一半，再找对应你脾气，你对应他脾气，最后只剩下几个人是最佳选择。再加上其它实际因素，你还能找谁做结对编程？
在中国，少听说有工程师是结对编程，我觉得，结对编程至少在中国，是一个偏理想化的编程方式。
第十七章：
问题一：关于P370萝卜白菜的故事，书中给出的答案是，团队的领导者文化决定了团队的风格。那么如果我刚进一个公司，我还不太清楚我所属的团队是什么样的风格。我该怎么做？踏踏实实的编码，考虑到各种异常处理，做好白菜，还是说做像个明星一样的萝卜？
我本身的行为习惯是做白菜，但是在刚进公司不清楚团队风格的情况下，我需要给自己曝光吗？
问题虽短，但这确实是我一看到这个故事就在思考的问题，至今还未有答案。