第四章做业

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）、按功能单元划分源码树，而不是按组织结构

６、结对编程中很差的习惯——你经历过么，如何提醒同伴改进

结对编程历来不是一我的的事情，所以咱们做为团队成员咱们要去遵照一些规范，这样才可让咱们的团队变得更好，才能让咱们的编程工做得以进行。首先沟通是必要的，咱们还能够制定一些行为规范和工做要求，在沟通时还要注意我的态度和规劝沟通的语气，尽可能委婉，要求同存异，尽可能达成一致。