第四章作业
1.结对项目的案例和论文。
http://c2.com/cgi/wiki?PairProgrammingCaseStudy
http://dwz.cn/1GOOvc
http://www.cs.utexas.edu/user/mckinley/305/pair-hcs-2006.pdf
2.性格对合作的影响
3.是否需要有代码规范
1. 这些规范都是官僚制度下产生的浪费大家的编程时间、影响人们开发效率, 浪费时间的东西。
反驳。
官僚制度:按照职能和职位分工,分层管理原则建立起来的行政权力体系。
这些规范是前人总结出来的,大家默认的可以看懂的代码规范。对于经常编写代码的人使用这些代码规范是方便的。在整个软件团队的工作环境中,它能够大幅度节约团队编程所需要的时间,提高团队的工作效率。也许代码规范会让刚接触的使用者感到束手束脚,但是熟悉之后,在程序的可理解性上得到的好处会大大的补偿之前的损失。
2.我是个艺术家,手艺人,我有自己的规范和原则。
反驳
特立独行对于开发者来说也许很合适,但是在软件团队的工作中,艺术家的行业道德并不合适。一个人的规范不叫规范,没有哪个人的个人规范和原则可以凌驾于团队规范与团队原则之上。如果因为一个人的个人规范和原则导致团队工作受到了严重的影响,那么这样的规范和原则不如没有。
3.规范不能强求一律,应该允许很多例外。
反驳
规范应该尽量一致,即使有例外,也只能是少数情况,而不能是很多例外。我个人认为例外多了,就不能叫做例外了。
4.我擅长制定编码规范,你们听我的就好了。
反驳
统一是有价值的,一个程序员永远不可能独自工作,在软件团队工作时代码规范是一定要强调的,这是团队积攒下来的经验。在团队工作中,完全遵守代码规范的收益是 降低阅读代码时候的沟通成本,但是在一个团队适用的规范和原则在另一个团队不一定同样适用。如果对现有的代码规范和原则有意见,可以通过一定方法修订并发布新的规范。但是在新的规范发布之前,遵守旧的规范,维护团队利益。
5 、阅读别人的代码有多难
关于自己编写代码时,如何让代码更易于阅读与维护。
归纳:
1)、坚持使用一种命名模式
2)、不要随意缩写英文单词
3)、使用断言来记录先决条件和后置条件
4)、C语言标准运行时库的设计不是很优秀。不要去效仿它
5)、不要写“聪明”的代码
6)、按功能单元划分源码树,而不是按组织结构
6、结对编程中不好的习惯——你经历过么,如何提醒同伴改进
结对编程从来不是一个人的事情,因此我们作为团队成员我们要去遵守一些规范,这样才可以让我们的团队变得更好,才能让我们的编程工作得以进行。首先沟通是必要的,我们还可以制定一些行为规范和工作要求,在沟通时还要注意个人态度和规劝沟通的语气,尽量委婉,要求同存异,尽量达成一致。