正文

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

ScottZZ  ScottZZ  2022-10-30  642

关键词：

一、前言

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

二、关于问题

第4章两人合作：

“匈牙利命名法”

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

第17章人，效绩和职业道德：

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

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

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

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

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

读《构建之法》第4，17章有感第四章：两人合作原文：另外，注释（包括所有的源代码）应该只用ASCII字符，不要用中文或其他特殊字符，否则会极大地影响程序的可移植性。我的问题和看法：对于英语水平没有那么高的人来说... 查看详情

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

第4章两人合作问题1原文：P69 4.3.2 goto函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto。问题：对于goto语句，大一上学期C语言老师总是跟我... 查看详情

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

第四章　　原文：　　　　4.3.2：goto函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto。　问题：　　　　是否什么地方都可以使用goto语句，为什么... 查看详情

《构建之法》第4章第17章阅读与思考

第四章两人合作原文：大家都知道用单个字母给有复杂语义的实体命名是不好的，在C语言家族中，比较通用的，也是经过了很多实践检验的方法叫“匈牙利命名法”。问题1：虽然看了书中接下来的一些解... 查看详情

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

...熹对阅读一本好书的感受。这几天我看了邹欣老师写的《构建之法》第4、17章之后，产生了一点点类似的感受。下面我来点评一下。关于“第4章两人合作”的点评：问题一：原文（见第68页）：另外，注释（包括所有源代码... 查看详情

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

一、前言经过上一次的阅读经验，这一次再阅读起来便顺畅得多了，顾名思义，这两章就是在讲我们如何在项目开发合作过程中更加顺利，软件工程既然有着“工程”二字，那就说明它并不是一个人的事情，软件工程离不开团队... 查看详情

构建之法第4.17章读书笔记

第四章：两人合作问题1：4.2中注释这一版块，因为之前有学长跟我强调过代码规范的问题，所以对这方面比较重视，后来当使用每个IDE的时候，都会去注意代码缩进的快捷键，比如IDEA的Ctrl+Alt+L等等；我对自己写的代码还算... 查看详情

《构建之法》第8-10章读后感

第八章：需求分析本章节讲述软件需求的4个步骤，（1）获取和引导需求（2）分析和定义需求（3）验证需求（4）在软件产品的生命周期中管理需求。在软件工程中分析软件需求需要考虑相关者的利益关系，例如用户、顾客、市... 查看详情

关于构建之法第第二与第十六章阅读疑惑

第一章、概论原文的1.2.1节中有说到软件的不可见性，其中有这么一段描述：“商用软件出现了错误，工程师可以看到程序在出错的一瞬间留下的一些痕迹（错误代号、大致的目标代码位置、错误信息），但是几乎无法完整... 查看详情

《构建之法》第13—14章

...用户的辅助功能、安全易用性是否能正常工作；三、测试构建是否成功，步骤是否顺利、功能特性是否全面；四，确认版本是否有进步、外部人员进行板块内测。从小到大查看详情

《2017011.17-构建之法：现代软件工程-阅读笔记3》

第九章项目经理PM：典型的软件团队里除了能写代码、测试代码和画图做设计的成员，还有一类角色，不做上面这些事情但也很重要，我们叫他们项目经理--PM微软PM的来历:交流成本问题、开发测试搞不定的事情PM的能力要求和任... 查看详情

《构建之法》第1.2.3章读后感

第一章概论，讲解了什么是软件工程，软件工程的重要的性质，软件工程与计算机科学的关系、知识领域，目标。我觉得用户满意的软件才是好的软件，在阅读时，发现几个以前没思考过的问题，如软件的可靠性、软件的bug、还... 查看详情

读《构建之法》

这周精读了几遍《构建之法》的一、二、十六章，本人更偏好于语言精练概况的书籍，由于语言习惯问题，这本书对我而言有些解读困难。由此在下面对几章内容精练出总结概况，并提出问题。第一章1.1软... 查看详情

教材《构建之法》第1.2.3章读后感

问题思考第一章什么是bug？课本29~31页有说到bug的大概概念，简单来说就是软件的行为和用户的期望值不一样，这就叫bug。这使我很困惑，世界上那么多人，肯定每一个软件都会和很多人的期望不一样的啊，这样岂不是每一... 查看详情

《构建之法》第11-12章读后感

第11章软件设计与实现满足用户需求的第一步就是分析软件需要些什么，就首先需要“需求分析”。之后就是软件的“设计与实现”阶段。最后就是质量的“测试”与软件的“发布”。这一章节重点就是完成需求中的第二步。在... 查看详情

我读《构建之法》十七章

...法》第四章和第十七章，看的比较缓慢也比较认真。根据精读的要求和个人看书的习惯，我总共读了三遍，第一遍是大致浏览了一遍内容，第二遍是静下心来圈画、标注疑惑内容，第三遍是重新浏览了一遍并解决了一些疑惑。这... 查看详情

《构建之法》第15章学习心得

软件开发过程是痛苦的，但是完成之后并不是就结束了。经历了计划、设计、开发等阶段，达到了代码完成这一目标之后，团队内部还要学会去发现修正已有的缺陷之后才发布。但是我觉得软件的隐藏bug会随着时间的延迟发掘出... 查看详情

阅读《构建之法》第四章第十七章收获

阅读《构建之法》第四章、第十七章阅读这一章的时候，我意识到了很多以前写程序没有注意到的地方，以前写程序就只知道能运行就好，根本不管自己写的程序占多少内存，运行的时间，是否有优化的空间，写代码的时候也不... 查看详情