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

第四章:

我看到这样一段文字:

反对解体阶段:好不容易找到合适自己的编程伙伴,并且磨合了这么久,为啥在完美解决一个问题之后就要走向解散,各找舞伴?那样岂不是走了弯路?那么我们在学校没做完一个结对项目,就要与我们结对的伙伴宣布解散?那么下一个结对项目开始的时候,我们又要花时间去适应搭档,去寻找灵感,很耽误时间,而且既然已经找到了一个非常好的伙伴,我想两个人可能会对用一个问题有着远大的目标和见解,为啥就要各走各的独木桥,两人磨合期也是需要很长时间的,所以我觉得找到一个非常合适的搭档之后,就不必在完成一个任务之后去解体,应该向着更大的目标前进。

第十七章:

相较于前面的结对项目,第十七章的团体项目倒是符合我的观点

这里对于团体是一个不断提升的状态,对于团体最少的是两个人,而仅仅两人已经很难磨合了,面对庞大的一个团体,磨合更是难上加难,所以不到万不得已,根本没有解体的必要,因为日后只会越来越好。

看到这样一段文字:

这里说完成一个项目或者任务后,我们要对合作伙伴进行评比,其实我觉得这完全没有这个必要,既然已经是一个团体了,每个人都有自己的见解,缺少了每个人都对这个项目有着必不可少的贡献,那我觉得其实每个人对团队的贡献都是“1”,没有必要还对每个人进行评比,因为可能一个人在这个项目里面干的活真得偏少,但至少他参与了这个项目,提出了一个想法,这个想法是你没有想到或者说出的,又或者这个想法被排除了,那即使这样,它也是对于这个项目给出了排除意见,每个人都有其必不可少的作用,因为最后完成的就是一个完整的项目,而并不是你的我的,和他们的子项目。

原文地址:https://www.cnblogs.com/weiwandaixuyun/p/8686797.html

时间: 2024-08-01 08:08:25

读《构建之法》第四,十七章有感的相关文章

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

通过阅读<构建之法>第十七章,不能说对我造成了什么深远的影响,但是还是感触颇深: 第一,工作分配的重要性,说道工作分配,不得不说我们个小组的组长们,组长不仅仅是一个团队的领导者,更是这个团队的灵魂.它不仅需要了解随时掌握各组员的动向,更重要的是,他需要了解各组员的能力,然后根据个人的能力,然后再去非陪相应的任务,只要这样才能做到“物尽其用”,才能更好的完成我们的项目,有时甚者能更创造出以外的效果,达到更完美的状态.这不仅是组长的能力  其实其无时无刻也体现着我们这个小组的团结力和创造力.当初选

读构建之法第四、十七章有感(作业四)

第四章: 问题: 看到这里的时候,才注意到代码中的"下划线"这个东西,在之前的敲代码过程中并没有怎么遇到下划线,在经过百度后得到了一些答案: 这只是Python中下划线的一部分应用,在不同的语言中,下划线的用处也不太相同,而在原文中作者对下划线的解释很简单,对于"下划线用来分隔变量名字中的作用域标注和变量的语义"这句话也不太理解,我认为作者可以适当地放一些代码片段来说明下划线的用法,如果作者提及下划线的原因仅仅是因为命名的话,我觉得完全可以放在下划线的上一小节&qu

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

第四章 1.原文:"函数最好有单一的出口,为了达到这个目的,可以使用goto.只要有助于程序逻辑的清晰体现,什么方法都可以使用.--P69" 问题:关于goto,我记得老师讲过,这个在编程中是尽力避免的,所以我在之前并没有了解过它.本书却建议用,这让我产生了困惑. 我的看法:goto语句它可以不受限制的灵活跳转,这样程序员在使用goto语句的时候就很容易因为跳转而略过了一些关键语句.但是它能从多重循环体中跳出,用不着写很多次的break语句.我查了一些资料,发现自从提倡结构化设计以来,

构建之法第十三~十七章阅读

不知不觉,<构建之法>已经读到了最后..... 十三章:软件测试 本书里面写了好多软件测试的方法,我该怎么选取呢 十四章:质量保障 质量保障可以通过用户的反馈来体现吗 十五章: 稳定和发布阶段 软件发布以后,可以怎样的情况来更新维护 十六章:IT行业的创新 我觉得创新是在你已经对本行业已经有一定的了解,但是我们好多基本的都还没掌握,该怎么创新呢 十七章:绩效和职业道德 在出去工作以后,公司都是以绩效和职业道德来恒定员工的吗

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

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

读构建之法 第四章:两人合作

程序员写的代码最终是人在看,所以代码规范很重要,原则是:简明,易读,无二义性. 不光是程序书写的格式问题,还牵涉到程序设计.模块之间的关系.设计模式等方方面面. 代码复审的正确定义看代码是否在代码规范的框架内正确的解决了问题 代码复审的目的在于: 1.找出代码的错误,比如: 1)编码错误,比如一些碰巧骗过了编译器的错误 2) 不符合团队代码规范的地方 2. 发现逻辑错误,程序可以编译通过,但是代码的逻辑是错的 3. 发现算法错误,比如使用的算法不够优化,边界条件没有处理好等 4. 发现潜在的错误

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

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

构建之法第四章学习心得

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

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

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

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

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