《构建之法》——软工学习进度(3)
合作与审核
首先是代码的规范问题。关于这个代码规范,我并没有花很多时间去阅读,可能是自己的习惯,代码风格一向都是简约而规范。就比如在写一些if语句的嵌套时,很多人都习惯了不加括号,即使加括号可能是多此一举但我还是习惯加括号,不为别的,就为自己甚至别人看上去能更加清楚,这并不是画蛇添足,我觉得更像是画龙点睛。不过这一节对变量的命名我倒是深有感触,我们习惯了教科书上的一些命名,所以有时候看到问题不假思索的就为变量命了书上常出现的名字。但是当我们之后再去复核时,我们往往不懂这些变量在这个问题中的意义,很快就忘了我们为这个问题所设的变量的作用。这是很麻烦的一件事,本来就是我们自己敲的代码,自己思考着写出来的逻辑,过了一段时间看着代码却不记得了,如果当初对一些关键变量的命名可以直截了当的点明,我们很快就可以想到以前的思路了。
其次就是注释。我们敲代码的时候都没有写注释的习惯,起码我没有。这一问题值得我去反省,写注释花不了多少时间,但是我们在敲代码的时候这些时间却显得弥足珍贵,其实注释是在帮助我们理解代码行的作用,并不是在浪费时间,跟变量的命名所起的作用相似,都是起到帮助的作用。
代码的复审有“教育”和“传播知识”的作用。重要的是,不管多么厉害的开发者都会或多或少的犯一些错,有欠考虑的地方,如果有问题的代码已签入到产品代码中,再要把所有的问题找出来就更困难了。我们学习软件工程的都知道,越是项目后期发现的问题,修复的代价就越大。代码复审正是要在早期发现并修复这些问题。除了代码复审以外,还有编程结对,在结对编程模式下,一对程序员并肩、平等地、互补地进行开发工作。他们并排坐在一台电脑前,面对同一个显示器,使用同一个键盘,同一个鼠标一起工作。他们一起分析,一起设计,一起写测试用例,一起做单元测试,一起做集成测试等等,这些搭档关系就是结对编程,也就是合作关系。
合作关系有不同的阶段。1、萌芽阶段。两人刚刚认识,大家都有礼貌,一般交流不少,试图避免冲突和容易引起挑战的观点。2、磨合阶段。手足无措,显得很笨拙。3、规范阶段。一些成文或不成文的规则逐步建立起来了。4、创造阶段。5、解体阶段。散伙。那么,在两个人合作阶段,如何说服对方呢?首先双方要意识到,问题早点出现要比晚点出现要好很多,我们有机会早日解决问题。除了技术方面的考虑之外,一个成熟的工程师要琢磨对方的话语和观察对方的肢体语言,了解它们所表示的潜台词。试着从对方的角度看待问题。同时也要根据情况采取不同的方法影响别人。书上写了几种影响他人的方法:断言、桥梁、说服、吸引。
总结一下这章内容,主要讲了我们程序员该如何规范的敲代码,让我们自己甚至别人能更容易的理解,以及如何合作、如何影响他人去接受你的观点。看完这章,我明白了团队中还有更小的团队,两人为一组时,必不可少的就是观点的碰撞,这时候需要的就是观点的陈述了,这一章对合作方面讲述的很深刻,让我对团队流程有了一个更深入的了解。