《构建之法》第13-17章

第13章（13.2.1）：如果测试出有错之后，我们应该如何改，如果改不了那么这个程序不就作废了？而且我们都这么费劲地测试了，那还要测试人员干什么？

第14章（14.2.2）：测试人员在团队中需要独立出来吗？为什么一些成功的公司不用测试人员？

第15章（15.1.1）：为什么有些优秀软件团队会发布有已知缺陷的软件，不担心用户发现有缺陷后不再使用他们的软件吗？是为了做更好的改善吗？

第16章（16.5）：我觉得其实为什么要在意这些创新的迷思和创新的时机？还不如从解决自己的问题开始做起，如果在意的话，那么很多人都不敢说出创新的想法了。

第17章（17.2）：17.1中说到团队合作中的几类人，如P1：做事的，P2：不做事的，P3：不让别人做事的，P4：做假的事的，P5：假装做事的，若是遇到P2-P5这几类人的话，我们应该如何处理，团队中是否要开除他们？

时间： 2024-10-13 05:23:24

《构建之法》第13-17章的相关文章

《构建之法》13~17章

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

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

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

阅读《构建之法》13=1章

第十三章:软件测试 怎么样才能全方位的测试一个程序?又怎么样确定这个程序测试没有遗漏? 第十四章:质量保障 程序质量好,那么软件工程的质量有影响吗? 第十五章:稳定和发布阶段 推迟发布行不行? 第十六章 :IT行业的创新 有需要就有创新,如何创新? 第十七章:人,绩效和职业道德 一个人说:我在这工作了十年,有了十年的经验,我要加薪! 老板说:你只不过是一个经验用了十年而已! 怎么判断谁是正确的? 博客<连载<一个程序员的生命周期>17.最后的项目,抑郁了>读后感: 作为一个程序员,

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

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

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

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

构建之法五、六章读后感

在本周我主要学习了构建之法的第五章和第六章,第五章主要讲述团队和流程,第六章主要讲述敏捷流程: 软件团队的模式有:主治医师模式.明星模式.社区模式.业余剧团模式.秘密团队.特工团队.交响乐团模式.爵士乐模式.功能团队模式.官僚模式: 开发流程包括:写了再改模式.瀑布模型.瀑布模型的变形(生鱼片模型.大瀑布带着小瀑布): Rational Unified Process统一流程(RUP):包括业务建模.需求.分析和设计.实现.测试.部署.配置和变更管理.项目管理.环境: RUP的四个阶段包括:初始

构建之法读后感----第1章 绪论

首先,文章对于程序.用户需求.工程等等概念用了阿超给儿子编写的一个出题程序来分别解释了个中的含义,尤其是程序和工程的区别,程序大概就是用很多语言或工具编写的一个简单能实现目标要求的一行行代码,而工程就是在这个程序的基础上不断满足用户的需求.修复程序的bug.提供后续维护等服务. 需求分析:梳理需求,逐步展开后续工作,如设计(软件架构).实现(写数据结构和算法),测试,发布软件 软件=程序+软件工程(软件企业=软件+商业模式) 软将工程的核心部分:构建管理.源代码管理.软件设计.软件测试.项目管理

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

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

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

这周我学习了<构建之法>第三章,讲述了软件工程师的成长.软件系统的绝大部分模块都是由个人开发或维护的.在软件工程的术语中,这些单个的成员叫做Individ-ual Contributor(IC).IC在团队中的流程是怎么样的呢?以开发人员为例,流程如下. 1.通过交流.实验.快速原型等方法,理解问题.需求或任务 2.提出多种解决办法并估计工作量 3.其中包括寻找以前的解决方案,因为很多工作是重复性的 与相关角色交流解决问题的提案,决定一个可行的方案 执行,把想法变成实际中能工作的代码,同时验证

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

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