读《构建之法》第4、17章有感

    诗云:半亩方塘一鉴开,天光云影共徘徊。问渠哪得清如许?为有源头活水来。

这是宋代理学大家朱熹对阅读一本好书的感受。这几天我看了邹欣老师写的《构建之法》第4、17章之后,产生了一点点类似的感受。下面我来点评一下。



关于“第4章 两人合作”的点评:

问题一:

原文(见第68页):另外,注释(包括所有源代码)应该只用ASCII字符,不要用中文或其他特殊字符,否则会极大地影响程序的可移植性。

个人见解:可移植性是指代码在不同平台能否执行。注释会被执行吗?不会。那么,注释就与可移植性无关。中文注释也是注释,所以中文注释也与可移植性无关。

问题二:

原文(见第73页):发现算法错误,比如使用的算法不够优化,边界问题没有处理等。

个人见解:“算法不够优化”不能算是“算法错误”吧!@邹欣老师



关于“第17章 人,绩效和职业道德”的点评:

问题一:

感觉这章干货很少(仅对我而言)。或者说,我在看完之后都没产生什么想法。



一本书,如果读者能够认真阅读,并在阅读后作出理性批判,那么,我觉得这才是对作者最好的尊重。与诸君共勉。

 

原文地址:https://www.cnblogs.com/FDDLC/p/8687073.html

时间: 2024-10-08 22:06:30

读《构建之法》第4、17章有感的相关文章

构建之法1,5,17章读后感触

看了构建之法1,5,17章的内容,我对团队有了新认识.在一个团队中,不同成员来自五湖四海,为了一个目标,走到了一起.所以,需要的是全身心的投入.但人资历,成绩,口碑有差别,这就有了好/中/差,三等待遇,所以付出的努力不同,得到的待遇自然而然也就不同. 在我们这次软工中,我们需要一个真团队,高效的团队,来互相提升帮助我们完成这些任务.在这过程中,我们需要负担起身上的责任和要对伙伴负责.这样才能让团队走向成功

读《构建之法》前三章有感

最近这几天一直下雨,我的心犹如构建之法一般的复杂,但是,听着雨声,仔细的思考后,感觉构建之法在我的心中慢慢的变得清晰了.这几天看了<构建之法>的前三章后,心有所感,在这里就粗略的讲一讲我的感想,首先是第一章,主要讲了软件工程师什么,软件又是什么,软件的各种要素等等,让我对软件有了一定的了解,同时深有所感的是,一个软件,不论好与坏,都是应人们需求所产生的,所有的软件都不是一天就可以完成的,有的需要很久很久,同时还需要一个团队的合作才能呈现出一个软件,软件工程这门学问不是一个理论的学问,更多的是一

《构建之法》13~17章

第十四章:问题:本章主要讲的是软件的质量和对软件质量的保障工作.而且开发过程的可见性有非常差.那么在我们接到一个项目时如果没有能力去完成它,是否放弃这个项目.但是没有挑战就没有进步,这其中如何选择?第十五章: 问题:文中(288)的例子中提到很多程序员都想在开发或是修改的时候加一些功能进去,但是这往往是不允许的,那么我们如何在这中间找平衡.即允许加进我们想加的东西? 第十六章: 问题:如今科技发达,社会进步快,相对一些科技技术更新也快.但是却很难在旧的领域有创新,而新的领域又很难开发.那么当我们

读《构建之法》第四章有感

第四章讲的只要内容是结对,也就是两个人合作,涉及到的理论和知识点有代码规范,极限编程,结对编程,两人合作的不同阶段以及影响他人的技巧.首先代码的规范性,一个不管再怎么牛逼的程序员,如果他写的代码杂乱无章,别人也不会认可他的.代码规范分两个部分,代码风格规范和代码设计规范,而风格规范中讲的是缩进,行宽,括号,断行,分行,命名,下划线及大小写.设计也包括11个内容. 接下来就讲了代码复审,写出来的东西一定要经过审核才能拿出来给别人用的,审核就是要找出我们代码的错误,发现逻辑错误,算法错误及一些潜在的

构建之法4,17章读书笔记

一.前言 经过上一次的阅读经验,这一次再阅读起来便顺畅得多了,顾名思义,这两章就是在讲我们如何在项目开发合作过程中更加顺利,软件工程既然有着"工程"二字,那就说明它并不是一个人的事情,软件工程离不开团队合作,而团队合作的最简形态就是两人合作. 二.分析与问题 引用:               既然代码复审能发现这么多问题,有这么好的效果,如果我们每时每刻都处在代码复审的状态,那不是很好么?事实上,极限编程(Extreme Programming)正是这一思想的体现--为什么不把一些卓

读《构建之法》第4,17章有感

读<构建之法>第4,17章有感 第四章:两人合作 原文:另外,注释(包括所有的源代码)应该只用ASCII字符,不要用中文或其他特殊字符,否则会极大地影响程序的可移植性. 我的问题和看法:对于英语水平没有那么高的人来说,不允许中文注释真的太难了.刚开始学习代码的时候,老师就教导我们编程的时候一定要写注释,但是并没有非常严格的要求我们必须要用ASCII字符.我上网查找了一些资料,发现大部分公司对于注释并没有明确的要求.注释是为了方便让别人理解你的代码的,所以简洁易懂应该才是最重要的,在水平达到的情

读《构建之法》第四章 、第十七章

第四章    两人合作 通过对于<构建之法>第四章的阅读使我对代码规范 . 代码复审 . 以及结对编程有了更加深刻的认识,所谓代码规范可以分为两个部分,代码风格规范和代码设计规范,代码风格规范的原则是:简明 . 易读 . 无二义性,代码书写的形式,变量命名的方法,注释程序如何工作都有详细的介绍,令我受益颇多.代码设计规范不光是程序书写的格式问题,而且牵涉到咸亨需设计 . 模块之间的联系 . 设计模式等方方面面,函数的设计,语句的使用,错误的处理,这些都是我们在进行程序设计的时候需要注意的地方.

读构建之法之感

读构建之法之感,为什么迟迟没有发构建之法这本书的观后感,是因为想要细细的看,为什么老师这么要求我们这么做,为什么要刻意的去发微博,原因都在构建之法的这本书中.构建之法这本书和其它的软件工程的书不同,构建之法这本书讲的清晰有趣,容易理解,不像其它的软件工程的书籍,写的那么的枯燥和乏味,构建之法的每章都有很大的联系,让人逐渐的去深刻的理解.通过构建之法理解并懂得什么是软件工程,软件工程是系统的,有序的,可量化的方法应用到软件的开发,运营和维护中去.希望通过自己的努力以及软件工程的课能够让自己有一个小

第五次作业《读构建之法的心得》

<读构建之法的体会> <构建之法>这本书是软件大大神邹欣的作品之一,这本书体现邹欣老师的情怀,很简洁的讲述了软件设计的各个阶段,描述了一个微软软件大神对软件的理解.构建之法对我帮助挺大的,通过构建之法这本书使我对软件的构建很清晰的了解,让我对软件设计更加的清晰的认识,增加了我对软件的认识的兴趣,好了,现在来讲述讲述里面的内容,第一张讲概论:软件等于程序加文档,软件工程是什么,第二章讲 个人技术和流程 单元测试,效能分析工具,个人开发流程第三章讲软件工程师的成长 个人能力的衡量与发展

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

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