第四、十七章读书报告
第四章:
问题一:第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萝卜白菜的故事,书中给出的答案是,团队的领导者文化决定了团队的风格。那么如果我刚进一个公司,我还不太清楚我所属的团队是什么样的风格。我该怎么做?踏踏实实的编码,考虑到各种异常处理,做好白菜,还是说做像个明星一样的萝卜?
我本身的行为习惯是做白菜,但是在刚进公司不清楚团队风格的情况下,我需要给自己曝光吗?
问题虽短,但这确实是我一看到这个故事就在思考的问题,至今还未有答案。