构建之法阶段小记四

转眼已是十一周,距离期末已很近了。加上有任务在手,渐渐地可能会忙起来,因而决定加快读书进度以期尽早完成基本内容的学习,在这样的环境下本周阅读了书中的第4、5章。

有句俗话说得好,众人拾柴火焰高。无论从事什么活动或者工作,多数情况下合作得到的结果都是1+1>2的。第4、5章就分别从两人的结对编程和大型的团队项目着眼介绍了软件的开发经历。软件开发的过程是复杂的,一个人单独开发一个软件的情形已经非常少见了。绝大多数的软件都是在相互合作中完成的,合作很大程度上实现了个体的优势互补,譬如有人擅长界面设计,有人擅长功能实现,这样的合作能减少工作量,问题一起解决、工作一起分担能使开发工作的效率大大提高。

合作是如此的重要,而个体间水平、习惯的差异又是必然存在且无法避免的,对从事同一活动的个体程序员进行相关的规范约束就非常有必要。作为编程人员,代码及编程的规范又是重中之重。要是一个团队高效的运作,代码的风格规范和设计规范必不可少。规范中最主要的原则是:简明,易读,无二义性。整体的风格上要便于阅读,如行宽、缩进、分行和括号使用等都可以纳入规范。此外要尽可能的使各个变量、函数从名字上就比较便于阅读,必要的解释说明也要加以注释。设计上则要尽量精简,现代程序设计中的绝大部分功能都在程序的函数中实现,函数设计实现的最重要的原则就是:只做一件事,并且要做好。并且函数最好有单一的出口,要注意程序逻辑的清晰体现。在实际操作中还要注意错误处理,使用面向对象语言时还要留意类的使用和设计。

除具体实现外最重要的部分当属代码复审,具体又可分为:自我复审、、同伴复审、团队复审。复审的目的在于找出代码中的编码、或不符合团队规范等方面的错误以及发现代码逻辑上和算法设计上的错误和可能需要优化的部分,发现潜在的错误或回归性错误以及可能需要改进的地方也是重要目的。此外,复审还起到传播知识、使程序设计开发人员互相教育的作用。书中则以不少具体的实操情形介绍了几种复审的规范和步骤。复审的一种特殊的极致情形就是结对编程,一对程序员共同、平等、互补地进行开发工作,进行着频繁的交流与检查,实质是就是不间断的复审与修改,这样一来程序中的错误就会少得多,初始的质量自然也就有了提高,从而省下很多过后修改、测试的时间。两人合作解决问题的能力更强,只要运用得当,结对编程能提供更好的设计质量和代码质量,也就取得了更高的投入产出比。书中则以交谊舞为例子简单介绍了合作发展的各个阶段,同时阐明了合作中非常重要的一个概念——如何影响对方。互相之间的反馈在合作中非常重要,而如何进行反馈以及具体的措辞则是一门学问。

有了两人合作的基础,第5章详细介绍了团队合作的概念。什么是团队?团队有一致的集体目标,队内成员有各自的分工、相互依赖的合作、共同完成的任务,一个团队的成员不一定要同时工作,但对彼此或多或少的会产生一些影响。书中介绍了一些团队组建的模式:一窝蜂模式、主治医师模式、明星模式、社区模式、业余剧团模式、秘密团队、特工团队、交响乐团模爵士乐模式、功能团队模式、官僚模式等等。也介绍了一些比较常见的开发流程,如写了再改模式、瀑布模型及其各类变形、Rational统一流程、渐进交付的流程等,同时引出了优秀的模式和流程的一些共有点(TSP原则)。

时间: 2024-10-13 01:46:48

构建之法阶段小记四的相关文章

构建之法阶段小记七

在之前学习了需求分析和项目经理的职责及素质后,本周学习了构建之法的第10章.这么久过去了,在长时间的理论学习之后学业上也临近学期期末了,学习第十章之后对几门课程的期末大作业也有一定的帮助. 第十章在需求分析的基础上进一步提出并解释了两个概念--典型用户和典型场景,并提出了针对不同用户进行功能开发的概念.满足一些典型用户和典型场景中产生的需求可以很大程度上使得我们的软件功能得到比较完备的实现. 用例一次在之前的学习中也多次接触过,现在算是对它有了进一步的认识.在认识并利用用例进行系统需求分析的时候

构建之法阶段小记六

本周学习了构建之法的第8.9章,总算是接触到了久闻未见的软件工程中的重中之重--项目需求分析,以及对需求和团队进行管理的重要角色--PM 我们都知道软件是由人手一行行代码写出来的,软件的存在也是为了满足人工作生活中的各种需要.如果软件开发没有目标,那写出来的代码不过就是26个字母及其大小写加上空格和一些特殊符号的随机组合罢了,没有实用意义.所以,代码的诞生一定是为了实现某个或某些具体的目标,也即这些代码最终成型后要实现怎样的功能.为了确立这样一个目标,我们就需要对最终使用到这些代码的人做需求分析

构建之法阶段小记五

本周学习了构建之法的第6.7章,在先前两人结对编程和团队开发流程的基础上对于软件项目有了更进一步的了解. 第6章以许多浅显的描述介绍了敏捷流程的一系列理论及其原则,最重要的即 找出完成产品需要做的事情.决定当前的冲刺需要解决的事情.冲刺及每日例会和最终发布版本给用户并在此基础上进一步计划增量的新功能和改进.开发过程中成员与外界的交流及成员自身注意力的集中往往会产生一定矛盾,在开发时团队成员一般不能直接被外部人士打扰,因而产生了"Scrum Master"这样的一个角色来进行成员及外界的

构建之法阶段小记三

本周已是学期的第十周,这周内通过书中第三章的介绍对如何成为一个合格的软件工程师及软件工程师在个体.团队中应具备的素养有了一些基本的了解. 软件开发流程不光是团队的流程,还包括个人开发流程.书中以足球队做类比,阐明了一个非常重要的概念就是--软件团队是由个人组成的,在团队的大流程中,是每一个具体的个人在做开发.测试.用户界面设计.管理.交流等工作.因此,个人能力的衡量与发展在团队合作中也非常重要,书中也介绍了几种比较妥当的个人评价标准. 软件工程师应该在不同阶段有以下几种成长:积累软件开发相关的知

构建之法阶段小记二

本周因几门课结课,加上参加了普通话水平测试,总的来讲有些忙碌.忙里偷闲,把上周看了少量的第二章作了补全,第三章也简简单单开了个头. 第二章中,仅凭简单朴实的文字,说来重点也不过几句寥寥,却让人了解到了软件开发中非常重要的几个环节:测试及能效分析.简单来讲,测试又分为几个模块.其中,单元测试又涵盖几个要求:好的单元测试应该在最基本的功能/参数上验证程序的正确性.必须由最熟悉的人(即代码作者)来写.单元测试过后,机器状态应保持不变,且测试要快,应该产生可重复.一致的结果.另外,单元测试的运行/通过/

《构建之法》第四&十七章读书笔记

 <构建之法>第四&十七章读书笔记 一.         前言 再次阅读<构建之法>,愈发被其中生动有趣的举例吸引.作为一本给予软件工程学生的书籍,其不以枯燥的理论知识为核心,而是基于对知识和方法的引导.本次研读的这两章内容主要涉及了代码规范,两人结对与多人合作的团队方面等相关知识,从其中逐渐明白与人相处作业等方面的技巧与艺术.以下是我对这两章节的思考与疑惑. 二.        第四章<两人合作>. 本章主要涉及代码规范,极限编程,结对编程,两人合作不同阶段,

阅读《构建之法》第四章感想

课下阅读<构建之法>第四章,自己有以下一些感想. 1.我们写的代码最终都是要给人看的,所以代码规范化是一个优秀编程员必备的良好习惯,而且若是在团队里工作,那么代码规范更加重要.编程人员要遵循的代码风格的原则是:简明,易读,无二义性.以后自己要养成规范代码的习惯. 2.复审也是不可缺少的一个步骤,软件工程中最基本的复审手段就是同伴复审,找熟悉代码,有经验的人来进行复审. 3.当今时代,一个人能发挥的力量越来越小,团队的力量日渐重要,因此,如何合作,很关键.两个人合作,如何影响对方,要因人而异,因

《构建之法》第四章

<构建之法>第四章讲的是两个人的合作.结对编程.结对编程往往只需花费大约一半的时间就能编写出质量更高的代码. 代码规范方面,在给函数或者类取名的时候要严谨,不能写一些没意义的名称:在一些代码后面可以加些注释来说明此行代码的作用,在复审方面,我觉得自我复审时最好的,刚写好的代码脑袋里印象深刻,能很好的解决逻辑错误和算法错误. 结对编程方面,书中生动形象的说明了开发者的搭档关系,在结对的时候怎么分配任务,怎么通力合作.互相帮助,在两人的合作过程中,怎么磨合.互相提高水平,在遇到问题或者矛盾的时候,

《构建之法》第四章读后感--软件工程

<构建之法>第四章读后感--两人合作 1.代码风格很重要,因为良好的代码风格,有益于两人的合作甚至多人的合作. 个人认为 : 良好的代码风格的培养就是 多去阅读别人的优秀代码 ,用于提高并且培养自己的代码风格. 2.关于结对编程的重要性 2.1 结对编程能提高设计质量与代码质量 2.2 结对有益于学习交流 3.如何结对编程 3.1 主动参与讨论,提出设计方案或者问题的解决方案 4.代码的复审 复审可以提高代码质量,优化项目性能.