精读《构建之法》第4章与第17章

一、前言

  精读书可以让人有不一样的收获,通过本次阅读我认识了不少之前从未注意过的问题。第4章中提出了许多编程方面的规范和两人合作结对编程的阶段和技巧,第17章有许多生动的故事来形容“人”“效绩”“职业道德”之间的各种道理,并提出了一些令人值得深思的话题,耐人寻味。但其中仍有些许不太清楚,或许也有些不敢苟同的地方。关于个人观点提出的问题,如下。

二、关于问题

第4章   两人合作:

“匈牙利命名法”

  对于代码规范之前也有涉及,之前提倡的命名法是“驼峰命名法”,因为初次接触了“匈牙利命名法”这个新名词所以略有不解,查阅资料后得知命名方式为:变量名=属性+类型+对象描述,每一对象的名称都要求有明确含义,可以取对象名字全称或名字的一部分。其实之前接触的“驼峰命名法”也有自己的特点因为使用的变量函数名字一般是带有对该算法的通俗解释的,且因为大小写字母而变得层次清晰,对比起来可读性很高更容易的在同行之间交流。那么既然他们都是有提倡的,将来在工作中是否两者都可以使用,如果现在就要养成习惯那应该是用哪一种比较好适应将来的工作要求呢?

第17章   人,效绩和职业道德:

“一个新人能加入一个团队,团队领导看重他什么?”

“所以我们要让‘萝卜快了不洗泥’的人慢下来,这样能减少他们的危害”

书中提到的只有“知识”“专业技能和职业技能”“投入程度”,而在我看来既然是在团队之中,是否还缺少了十分重要的一点“团队意识和大局观”呢?一个新人拥有丰厚的技能和知识储备,倘若只是自己成长,会否略显孤傲呢,毕竟一个复杂的项目永远不可能是一个人就能够完成的。另外就是大局观,团结他人,有余力时帮助同事共同进步的好性情,应该是会更为领导待见的吧。

其中“萝卜与白菜”的故事也引起了我的思考,书中最后的解答是偏向了白菜,而否定了萝卜,在我心里留下了些许疑惑,难道萝卜这样一群人就真的是危害一个团体的存在?假如在一个团队里,白菜与萝卜比较,我们真的应该是更看重高质量完成任务的白菜而去抑制住萝卜的速度?在我个人看来应该是不一定的吧,萝卜与白菜各有用处,应该是不能一概否定又全部认可。在萝卜中也会有好萝卜与坏萝卜之分,我所理解的好萝卜是那种在错误中学习并不断完善自己,提升自己工作效率的技术人员,与一味就知道为速度犯错的萝卜相比,最好区分的特点就是在不断犯错中会否不断修正自己的错误,为维护人员和整个工程着想,顾全大局一错不再二犯或多犯,程序设计越来越有规范和条理。随着速度的提升工程量的加大,毫无疑问这群萝卜在将来必定是无论见识,还是学习能力都会远超其他人。在程序开发中,即使是对于白菜而言犯错也是不可避免的,改错能力有时也会成为一种优势。另外就我个人所知,太过于中规中矩,按时完成,也可能是一种应付任务的消极状态吧?很多时候作为程序的开发者维护者,交给自己完成的时间有时也是十分有限的,尤其是维护阶段,因为可能成千上万人正在等着使用,此时好萝卜是否更占据优势呢?所以个人感觉两者都应该是团队中不可或缺的吧,只是要合理分析他们的利弊。

原文地址:https://www.cnblogs.com/liuz100/p/8684860.html

时间: 2024-12-25 09:16:40

精读《构建之法》第4章与第17章的相关文章

《构建之法》13,14,15,16,17章读后感

1.13章说的是软件测试,怎么样去测试是最有效率的? 2.14章说到质量保障,具体的花费是多少? 3.15章说到ZBB,如果一个软件遇到了不可修复的bug,还算是一个稳定的软件么? 4.16章说到创新,有实际例子吗? 5.17章的职业道德指的是什么?

构建之法:1、2、3章阅读后感

第一章 第一章中主要说的是软件工程的一些概论.阅读完<构建之法>的第一章,初步了解了开发软件的大致过阶段,了解了软件工程的特性,明确了开发软件的目标.在这章节中,解析了软件工程的概念,从实际软件开发的各个阶段出发,详细地分析了软件开发的各个阶段,推翻了以前我们单纯的打完代码后就算编程完成的想法.初步了解了软件工程的目标,个人与团队合作之间差别. 问题:软件行业前景? 第二章 第二章涉及到了一个新名词:单元测试.书中提到单元测试对一个好的软件起着重要的作用,一个好的单元测试应该是准确.快速地保证

读《构建之法》1,2,3章后感

读完构建之法1,2,3章后,我对软件工程有了初步的了解,所谓的软件工程就是一整套的开发,运营,维修等流程,软件工程把这流程规范化了.我明白了软件开发过程中遇到Bug是很正常的事,这需要我们开发者去通过多次的JUnit去排除,修复Bug,以达到软件的正常运行.而完成做好这些工作需要一个好的软件工程师,需要一个好的软件开发团队,一个好的软件工程师要有一个好的开发习惯,更需要熟悉掌握一定的软件开发知识技巧,而掌握这些东西需要程序员不断去学习知识,总结经验,使自己 达到一定的等级.看完书后,我深知自己还

《构建之法》阅读笔记第十&amp;十一章

<构建之法>第十&十一章主要讲述了在软件设计前期的需求分析问题上的方法和实践经验,分为“典型用户和场景”以及“软件设计与实现”.其中第十章大部分内容和教授上课所讲的一样比如说,用户的分类(典型用户可以包括以下内容: 1. 名字(越自然越好) 2. 年龄(不同年龄和收入的用户有不同的需求) 3. 收入 4. 代表的用户在市场上的比例和重要性(比例大不等同于重要性高,如付费的用户比例较少,但是影响大,所以更重要 5. 使用这个软件的典型场景 6. 使用本软件/服务的环境(在办公室/家里/沙

Week2-作业1 《构建之法》1、2、16章观后感

这几天阅读了<构建之法>中的几章,受益匪浅,刷新了很多我对软件工程的认知.这本书让我很惊喜,阅读起来不像其他书一样枯燥,有很多人物的设计,以及对话的形式,非常有趣. 第一章.概述 读完第一章了解了软件工程具体是什么,以及它与类似计算机科学等的区别,还有对bug的定义,以前觉得软件工程和计算机差不多,看了书过后才发现其中的不同,一个比较偏科研,一个比较偏实践,悟清了许多之后,还有一些不太能明白的问题: 问题1: 我看了这一段文字 "中国大陆的高校中大致有下面三种将计算机软件的机构:计算

构建之法第一、二、十六章

<构建之法>第一.二.十六章疑问 我通过阅读发现这是一本十分有趣的书.不同于别的书的晦涩难懂,<构建之法>利用浅显易懂的语言,贴近生活的例子向我们讲述了软件工程的内容. 第一章  概论 软件=程序+软件工程 扩展:软件企业=软件+商业模式 软件工程是把系统的.有序的.可量化的方法应用到软件的开发.运营.和维护上的过程.软件的特殊性有a.复杂性 b.不可见性 c.易变性 d.服从性 e.非连续性.软件工程与计算机科学的区别:计算机科学中与实践相关的部分,都和数据以及其他学科发生关系:

构建之法第5词作业(12-15章)

第十二章 写了关于软件的用户体验,用户体验的要素:1.用户的第一印象.2.从用户的角度考虑问题.3.软件服务始终记得用户的选择.4.用户的体验和质量. 第十三章   软件测试 这一章介绍了很多关于测试的方法,比如说单元测试,代码覆盖率测试,构建验证测试,验收测试等,我有一个很纠结的问题,如果我开发软件,是把这么多测试全做完,还是挑一些测试来进行呢?如果挑一些测试进行,又很怕这个软件存在未知的缺陷,如果全部测试都做的话那需要庞大的人力物力.但是一个程序的稳定性离不开测试,所以我们可以在抽样的基础上

《构建之法》1、2、3章读后感

第一章 看了大概了解软件从一个想法到最终成品的一个过程.软件先是由一个想法引出的,有那个想法,你需要一个工具去做什么,然后根据自己想要的功能大概做一个能实现基本功能的软件,再对客户提出的要求进行完善,实现了功能后对软件进行维护. 还有就是做的软件要符合客户的要求,而不是只根据自己的想法去做,要满足大部分的需要,满足客户的需求,在使用过程中发现有bug对其进行修复. 第二章 看完第二章后知道软件是需要单元测试的,之前对这个没什么概念,而且单元测试要跟软件更新同步,单元测试要覆盖所有代码路径,单元测

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

第四章 在这一章最后一页" 让{}独占一样还有一个好处:一眼就能看出是否有多余的代码行 ,还有些情况下是致命的错误"给出的参考链接http://lpar.ath0.com/2014/02/23/learning-from-apples-goto-fail/,我还是没明白{}的致命错误在哪里,我不明白,链接中的代码 if(err) { goto fail; } 英语太差,我不确定,链接是不是在说,去掉{}会让这个语句执行出不一样的结果?这个我就很不明白,明明这段代码加不加括号都无所谓,我