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

昔陌上 昔陌上     2022-10-29     439

关键词:

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

一.         前言

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

二.        第四章《两人合作》。

       本章主要涉及代码规范,极限编程,结对编程,两人合作不同阶段,影响他人技巧几方面的知识点。以下是我的问题:
1. 原文:注释(包括所有源代码)应该只用ASCII字符,不要用中文或特殊字符,否则会极大的影响程序的可移植性。

根据对注释的解释,注释就是对代码的解释和说明,其目的是让人们能够更加轻松地了解代码。注释是编写程序时,写程序的人给一个语句、程序段、函数等的解释或提示,能提高程序代码的可读性。注释是为了让人们了解代码,为什么只能用ASCII字符,对于使用别的语言的人来说,强制使用ASCII注释会不会增加对注释的理解难度。对于中文注释的问题,是不是应该适度放宽,毕竟注释就是为了能让简单直白的明白代码而存在的。

根据知乎上的“大型公司代码注释是怎样?”这个问题有以下评论。

                       

                       

                    

       在我看来,ASCII注释可能在国际的运用率和广泛度比较高,因而导致的此种注释规范。但是根据实际情况,结合平常习惯和以上评论,我认为因地制宜的代码注释可能会比固定的代码规范在一定程度上效率更高。对于内部而言,只要能使团队人员理解,代码注释风格可以随自己决定,但在交流学习方面,可能ASCII注释的广泛度会更高

关于编程注释规范方面的博客:https://blog.csdn.net/xiaoxiaopengbo/article/details/51583631

2.原文:

“软件工程中最基本的复审手段,就是同伴复审。

谁来做代码复审?即最有经验,熟悉这一代码的人。对于至关重要的代码,我们要请不止一个人来做代码复审。”

“在代码复审中发现的问题,绝大多数都可以有开发者独立发现。从这一点说,复审这是在替开发者干开发者本该干的事情。”

  既然绝大多数问题都可以有开发者自己发现,那么代码复审的基本不应该是自我复审阶段吗?为什么会说同伴复审是最基本的?对于最有经验,熟悉这一代码的人来做代码复审,如何保证复审者对代码的熟悉?对于新人而言,经验可能不足,为什么通过复审来学习先进的代码?

对于开发者而言,自我复审可能会因为自己的过度自信而导致复审效率不高的问题出现。所以请不止一人做代码复审是有必要的。即使是很完美的代码,也具有教育和学习的功效,对于复审者而言也是一种成长。因此可以在有经验审查者审查后再次复审以期得到学习。

但对于如何保证对代码的熟悉?熟悉到何种程度才能作为复审者有衡量标准吗?

3.为什么结对编程?结对编程能否大幅度提高效率?

“结对编程让两个人所写的代码不断的处于“复审”的过程,程序员们能够不断的审核,提高设计和编程质量,可以及时发现并解决问题,避免把问题拖到后面的阶段”这样对效率的提高有好处,但会不会出现两人在磨合阶段导致效率低下,共同编程真的会比个人编程效率高吗?1+1>2并不适用于每个结对编程。

               

              

               

       以上评论来自于“工程师结对编程能否大规模提高效率?”,由此可见,绝大多数工程师对此种结对编程的评价都很好,但在具体实践过程中却出现问题。问题并不是处在效率上,而是在工程师工作方面的前提要求很多。很多评论都提到了高强度长时间的工作,以及水平相当的程序员能更好的完成。如果两个人在水平方面相差很多或者磨合期间出现问题,会不会导致结对效率还不如个人效率高的情况发生?在无法保证结对双方都满意对方,或者两人水平相差悬殊的情况下,又该如何调整和改变呢?

参考评论:https://www.zhihu.com/question/20188422

三.  十七章《人,绩效和职业道德

       本章节是对分配,绩效,团队成长阶段和职业道德等方面的分析,首先先以猪,鸡与鹦鹉的动物体系反映真实的工作体系以及对于工作分配绩效调整方面的理解。然后再展示团队成长的不同阶段和处理分歧的方法。最后点明软件道德规范。

    对于这个章节,我有以下的思考和想法。关于如何作为一名优秀的领导者? 怎样的猪,鸡和鹦鹉的分配比例更有利于团队长效发展,在绩效方面他们的评定方式又该如何?对于道德规范的要求,是否该随着客户需求而进行适当转变? 
    在我看来,在软件团队的中的领导力有几个要素:
*  设定目标
*  知人善任
*  带领团队解决问题
*  绩效管理
        工作分配的重要性。对于工作分配,作为一个团队的领导者,更是这个团队的灵魂。领导不单是管理方面,更应该侧重于领导的作用。它不仅需要了解随时掌握成员的动向,更重要的是,他需要了解各组员的能力,然后根据个人的能力,然后再去分配相应的任务,只要这样才能做到“物尽其用”,才能更好的完成我们的项目,达到更完美的状态。这不仅是领导的能力的体现,也体现着整个团队的团结力和创造力。作为一个集体,为了共同的目标而努力奋斗是必要的,这个过程就是团队成长的不同阶段,在磨合期也许会有不同的想法和思维导致矛盾,这是就要体现领导的作用。不是一概而论或者唯我独尊,而是倾听成员声音找到一个更好的权衡方法,在尽可能使大家满意的基础上去完成,这才是一个领导的作用。 
       一定比例上的三者协调在提高效率方面是有益处的。在实际的工作中,这些存在都是有一定作用和必要性的。遵循“重大决定由“猪”负责”的原则是现实的。所以这三种不同的存在是合理的。但对于如何协调之间比例的问题上,可能还是需要各自根据自己项目的要求进行调整。但这三者的绩效管理问题,如何分配和权衡还是一个需要考量的问题。书上所述的区别对待,根据完成任务维度和团队贡献维度形成的二位评价体系,可能是区别对待的一个较好的解决方式。那么猪,鸡和鹦鹉都充斥的团队,也适合这种区别对待的绩效评定吗?

       关于道德规范问题,“这并不是一个简单的道德算法,并不能产生所有道德上的决定”,所以“解决道德冲突最好的方法是对基本原则进行全面的思考,而不是盲目某些具体条目。”由于软件工程的多变性和苛刻性,应对新情况发生的道德规范在很大程度上还是需要工程师的自我约束和道德规范。面对纷乱复杂的市场和竞争,保持职业操守是很重要的事。面对不合理的客户需求,不能一味追求经济利益,更要考虑长远发展和社会影响。因此“软件工程师应当终生学习以提高自身的专业水平,并在工作实践中推动落实道德准则”。

 

 

构建之法第七,第十七章读书有感

第四章两人合作  关于合作中算法的使用   在第四章的叙述中,我们看到了代码的编写规范,代码的命名规范,我们还知道要写注释,要有良好的代码设计和错误处理。而这些都是我们在使用语言进行编辑中的问题。我们... 查看详情

week4-作业1:《构建之法》第四章第十七章阅读笔记与思考

第四章 两人合作  这一章是讲述了两人结对编程的一些东西,包括一些代码的规范,还有结对编程的优点、怎么做、以及一些注意事项。1、“错误处理当程序的主要功能实现后,一些程序员会乐观地估计只需要另外20... 查看详情

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

第四章   两人合作  通过对于《构建之法》第四章的阅读使我对代码规范、代码复审、以及结对编程有了更加深刻的认识,所谓代码规范可以分为两个部分,代码风格规范和代码设计规范,代码风格规范的原则是:... 查看详情

我读《构建之法》十七章

      这几天我都在读《构建之法》第四章和第十七章,看的比较缓慢也比较认真。根据精读的要求和个人看书的习惯,我总共读了三遍,第一遍是大致浏览了一遍内容,第二遍是静下心来圈画、标注疑惑内... 查看详情

第四章,十七章读书笔记

第四章,十七章读书笔记 第四章:1)我对于之前的如何简化代码,使代码更加易懂,如何复审等内容没有异议。我对结对编程有些问题。本章题目是两人合作,但在合作方式上却只有一种。这种方法跟我想的很不一样。我以... 查看详情

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

第四章:我看到这样一段文字:反对解体阶段:好不容易找到合适自己的编程伙伴,并且磨合了这么久,为啥在完美解决一个问题之后就要走向解散,各找舞伴?那样岂不是走了弯路?那么我们在学校没做完一个结对项目,就要... 查看详情

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

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

《构建之法》读第十七章收获(代码片段)

《构建之法》读第四、十七章收获第四章两人合作读了第四章,我才意识到代码规范的重要性,代码不仅要自己看懂,也要能让别人看懂,代码规范能使团队合作更好的进行。代码规范分为代码风格规范和代码设计规范。其中代... 查看详情

《构建之法》第四章十七章阅读与思考

  第四章:两人合作    引文:身旁这个家伙老是问问题,他/她不会看书吗?我都无法专心工作了。          如果软件工程师连一对一的合作都做不好,不能有效地去影... 查看详情

关于《构建之法》第四章和第十七章的问题(代码片段)

关于《构建之法》第四章和第十七章的问题第四章:问题一:在关于“缩进”,书中不提倡用tab键。而建议使用四个空格。但是tab键可设置占符数,在实际开发中,tab键是缩进的快捷键,我无法想像每次使用缩进都要敲四次空格... 查看详情

构建之法第四章第十七章

一、关于goto函数:滥用goto语句会使程序变得很难理解,而不是所有人能正确的使用goto函数,我的问题是:是不是因为这样所以很多文档规定禁用或少用goto函数?但其实如果可以正确的使用goto语句就不能说程序结构坏了?所以... 查看详情

读《构建之法》第四章第十七章(代码片段)

第四章《两人合作》1.原文:“注释(包括所有源代码)应该只用ASCLL字符,不要使用中文和其他字符,否则会极大影响程序的可植性”疑问:引擎根本不对空行和注释进行解析,直接忽略掉,它们不参与计算代码行数也不参与... 查看详情

读构建之法第四章第十七章有感

第四章 1、原文;“函数最好有单一的出口,为了达到这个目的,可以使用goto.只要有助于程序逻辑的清晰体现,什么方法都可以使用。——P69”  问题:关于goto,我记得老师讲过,这个在编程中是尽力避免的,所以我在之... 查看详情

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

书是我们永远的朋友它陪伴我们走过人生的春夏秋冬在我们的生命中生根、发芽、枝繁叶茂书是人类发展的录像机我们可以在其中看到前辈的足迹 书是知识的海洋我愿是一叶轻舟,载着理想之帆在海面上荡漾它蕴含着祖祖辈... 查看详情

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

第四章问题:如果另一个合作者不合作的话,我是应该选择脱离这个团队还是去催他工作? 本章讲了许多关于结对编程的内容,文中写了结对编程的分工问题,结对过程中会出现的问题以及结对合作的不同阶段。 正常来... 查看详情

读书笔记(代码片段)

前言  这个星期我仔细阅读了《构建之法》的第四章与第十七章,感触颇深,学习了很多,在此提出自己的问题和部分看法。  第四章两人合作 P74注释  注释(包括所有源代码)应该只有ASCII字符,不要... 查看详情

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

第四章  问题1:程序各方面的质量只取决于水平较高的程序员么?  引用:在结对编程中,因为有随时的复审和交流,程序各方面的质量取决于一对程序员中各方面水平较高的那一位。   结对编程在我看来是一种合... 查看详情

谈谈我对构建之法第四章与第十七章的理解

第四章:两人合作 问题一:  引用:“对于至关重要的代码,我们要请不止一个人来做代码复审”   理解:我对于这句话有些疑问甚至有些反驳。首先我觉得每一段代码都是应该被重视的,也许对于一个刚... 查看详情