《构建之法》第4章的感悟

第四章

看了第四章后,了解了第四章是两人合作的概论。

两人合作写软件首先要代码规范,进一步阐述就是要代码风格规范和代码设计规范。代码风格规范对于结对来说首先要统一开发工具,然后要注意源文件的格式、排版、换行、适当的注释、命名规范。即要简明,易读,无二义性。代码设计规范:对于函数来说。即用简单的构造函数,最好是默认构造函数,这是因为简单的构造函数增强易用性;对于错误处理来说。包括(逻辑和编程错误,设置错误,被破坏的数据...),然后要对程序增加一些相应的错误处理;对于异常处理来说。不是百分之百确定的情况,不要吞掉异常。如果理解该异常在具体环境当中产生的原因,建议捕获特定类型的异常。要在捕获并重新抛出异常时使用空的throw语句,这是保持调用栈的最好方法。

接下来就是代码复审,在软件开发项目中同行代码审查是一种常见的做法,而最基本的复审手段就是同伴复审。代码审查有助于识别潜在的Bug以及规范项目编码标准,对项目和团队的确有很大帮助。代码审查涉及四大领域,开发者自身、审查者、学习者以及传教者。可以说,贯穿整个技术和知识领域,所以同行审查能够提高团队的平均技能水平。此外,它还具备了无形的压力促使开发者更写更好的代码。其次,理解从代码中捕获的功能有助于在整个团队成员之间传播(共享)系统知识。还有,团队整体完成的项目质量要远远高出开发者独自完成工作的总和。而且,每位开发者都可带来不同的技能,实现协同编程,为团队“添砖加瓦”。总之,代码复审不仅是关注代码,而且还能见证整个团队的成长,它使整个团队间更有凝聚力。

接着是结对编程。简单来说是,2个程序员、同一套设备、一起工作、一起分析、设计、写测试用例、编码、单元测试、写文档,平等互补地工作。更形象的说是,一人充当“执行”角色,只负责编程。另外则负责“观察者”(或“导航”),检测bug和把控整体设计。与两位程序员各自独立工作相比,结对编程往往只需花费大约一半的时间就能编写出质量更高的代码。如果你是执行者,当以最快的速度完成了某个程序时,往往会忽略一些问题,在这个时候,搭档就是保障。如果你是观察者,仔细审查对方的代码,考虑可能的错误,以及如何简化和改进设计。此外,由于执行者的工作繁杂,所以切换角色有助于提升能力。所以至少每半小时转换角色,全力投入并适应不同级别的工作。还有,不管是谁掌握宏观方向,谁负责细节,最重要是配合默契高效完成工作。

最后是两人合作的不同阶段和技巧。以鄙人之见,结对双方相关性最强、区别性最大的因素是他们两人的效率差距。很多东西会影响程序员的效率,包括他们先前的:背景、个性、技能、经验、文化背景、领域知识、语言知识等。如果我们把这些综合起来,我们就能得出“效率”。考量“效率”可能还有另外一种方式,看他们产出的潜在强度,即完成编程的速度与质量。当结对双方开始进行有效地工作时,往往有很多的事情需要考虑,所以要经常讨论交流。对我来说,结对编程和技术相比,人的因素同样重要。因为和他人一起工作编写软件,很显然技术是必须的,但团队合作意识同样重要。

最后的最后希望结对编程愉快!

时间: 2024-11-03 21:47:28

《构建之法》第4章的感悟的相关文章

构建之法<第四章>之感悟

第四章:两人合作内容出处:4.6 两人合作的不同阶段和技巧 本章主要是讲关于合作方面的,文章以刚刚认识的两个人为例!也就是说,他们之前的关系是陌生人,然而在现实当中两人合作也可以有其它的关系,比如说合作的两人彼此是情侣关 系,那应该怎样合作呢?如果男的与女的合作前,男的对女的千依百顺,再合作时,当女的意见是错误的并且女的非常强势,而男的意见是正确的,这种情况之下应该怎么办呢?又 如,如果合作的两位伙伴,在合作之前是师生关系,这样又怎么办呢 另外我也和别人合作过,不过我们到了磨合阶段后就永远停留在

《构建之法》第一章读后随笔

<构建之法>第一章首先提出了“软件=程序+软件工程”的观点,然后介绍了软件开发的不同阶段,最后阐述了软件工程是什么的问题.这让我对软件工程有了新的认识,也对构建之法的重要性有了更为深刻的理解. 其实很多工科的很多道理都是相通的.不光是在软件工程,几乎的所有工程中,当工程规模到达了一定的数量级,就不可能是由一个人的一己之力能够完成的,这就需要相互协作,每个人只能做自己的一部分工作.如何能够让别人理解自己的工作的作用,如何能让每个人的工作都能融入一个系统,这就需要模块化,需要集成,话句话说,就是需

构建之法第六章学习心得

这周我学习了构建之法第六章敏捷流程,本章主要介绍了敏捷流程及其原则,Backlog.Burn-down.Sprint.Scrum方法论.以及什么时候选择敏捷的开发方法,什么时候选择其他方法..敏捷开发的原则是尽早并持续地交付有价值的软件以满足顾客需求敏捷流程欢迎需求的变化,并利用这种变化来提高用户的竞争优势经常发布可用的软件,发布间隔可以从几周到几个月,能短则短业务人员和开发人员在项目开发过程中应该每天共同工作以有进取心的人为项目核心,充分支持信任他们无论团队内外,面对面的交流始终是最有效的沟通

《构建之法》第一章读书笔记

工程有了一个初步的了解.介绍了软件工程里的一些基本概念,软件开发的几个阶段.软件工程的特殊性.目标以及软件工程与计算机科学之间的联系与区别.    软件工程作为一门新兴的学科,是连接计算机硬件和传统机械工程的一个桥梁.起先,我所认为的软件工程单纯的只是编程,通过算法实现正确的输出而已.但在构建之法的第一章中,我认识到会写程序只是一个合格的软件工程师最基本的素质.一个完整的项目,应该在需求分析,软件构架设计.代码实现.程序测试.软件发布运营及维护每个阶段都尽职尽责,并结合用户体验去完善软件的每一个

构建之法第四章学习心得

今天我学习了构建之法第四章,主要讲述了两人合作的理论和知识点.合作,无论在任何领域,都是不可缺失的,往往能产生不可替代的效果.同样在软件设计中也是如此,经过我的学习,我了解到软件设计中两人合作主要包括包括代码规范.极限编程.结对编两人合作的不同阶段以及影响他人的技巧. 其中最让我印象深刻的是代码规范.包括:代码风格规范和代码设计规范,代码风格规范主要是文字上的规定,看似表面文章,实际上非常重要:代码设计规范牵涉到程序设计.模块之间的关系.设计模式.等方方面面的通行原则: 同时,我了解了代码风格规

《构建之法》第一章概要及读后心得体会

1551427    钱洪章 首先知道:软件=程序+软件工程 名句:程序=数据结构+算法 提出疑问:"程序"是什么? 这里的程序指的是源程序,就是一行一行的代码. 软件够贱的过程:不仅仅是cc和link命令,一个复杂的软件不但要有合理的软件架构.软件设计与实现,还要有各种文件和数据来描述各个文件之间的依赖关系.编译参数.链接参数,等等. 新名词:源代码管理(配置管理).质量保障.软件测试.需求分析.软件维护.软件生命周期.软件项目的管理.软件的用户体验.商业模式 会得到一个扩展的推论:

构建之法第三章读书心得

在构建之法第三章中,我们主要学习了个人能力的衡量与发展. 初级软件工程师有以下几个成长阶段:1.积累软件开发相关的知识,提升技术技能. 2.积累问题领域的知识和经验. 3.对通用的软件设计思想和软件工程思想的理解 4.提升职业技能 5.实际成果 软件开发的工作量和质量你的衡量标准:1.项目.任务有多大? 2.花了多少时间? 3.质量如何?交付的代码中有多少缺陷?

邹欣老师的《构建之法》第一章“概论”学习笔记与自我随笔

刚读完了邹欣老师的<构建之法>第一章“概论”,四个字形容:酣畅淋漓. 概论将自己的一些模糊的认识清晰化,用准确的文字描述了出来,填补了脑海里的一些灰色地带. 总结一下:概论通俗地阐述了编程.软件.计算机科学.软件工程的联系与区别,简单说,编程是一项具体动作,软件是供人使用的产品,具体有很多种类型,而计算机科学是偏向理论研究,软件工程就像其他工程学一样,是在一定条件下合理配置资源达到生产软件的目的. 本人作为一名从小对编程.软件.计算机感兴趣的Nerd,虽然大学专业与此无关,但刚毕业时签了一份软

构建之法第七章学习心得

这周我学习了构建之法第七章MSF的介绍.MSF有9个基本原则,针对信息共享,团队内部运营,市场,还有客户.同样是强调效率,人性,灵活,还有前景. MSF对信息共享和沟通十分强调,对团队内部运营强调相互信任,各司其职.MSF敏捷开发模式分为两支,MSF敏捷开发模式和MSF CMMI开发模式.都是很人性,灵活,以及对自身有高要求的模式.结合上一章的敏捷流程和这次学习的MSF,在我看来相对比较迅捷,给人一种少了很严肃气愤的方法,个人还是比较喜欢.MSF的最大特性是商业化,并一直体现在项目的实施过程中.

《构建之法》第一章学习

<构建之法>第一章学习 1.软件工程的定义 软件工程是把系统的.有序的.可量化的方法应用到软件的开发.运营和维护上的过程.人们在开发.运营.维护软件的过程中有很多技术.做法.习惯和思想体系.软件工程把这些相关的技术和过程统一到一个体系中,叫"软件开发流程".软件开发流程的目的是为了提高软件开发.运营.维护的效率,并提高软件的质量.用户满意度.可靠性和软件的可维护性. 1.1软件的特殊性 软件是可以运行在计算机及电子设备中的指令和数据的有序集合,软件的主要形式有: 系统软件: