关键词：
第四章
问题1：
我对于书中的一段
有些疑问，这段书中说，不要注释程序是怎么工作的，而要让程序本身来说明这个问题。
我认为比较简单的代码确实不需要解释程序是怎么工作的，但是有时候为了两个人更好的配合，对于较复杂代码，也需要解释一下程序是如何工作的，这样子有利于对方更快的理解你的代码。
我从网上找的对于注释的作用如下：
代码注释的重要性
其实代码注释的重要性我倒是觉得没必要在这过多的解释，我们只要回想一些情景就能知道其道理：
1、当你经过一段时间后，发现哪儿出问题或需要调整功能的时候；
2、当你去改别人代码的时候（你的代码也会被别人改）；
3、当你需要补一些设计文档的时候（比如现在的我）；
我发现很多时候注释有利于他人去改你的代码，而我觉得如果不去注释代码是如何运行的，而只是注释代码是做什么的，为什么要这么做的话，肯定是不够的，改代码的人可能凭借着自己的主观想法就去修改，然后产生的后果可能会很严重。
问题2：
我对这段存有疑问
这段的重点是通过不断的复审来减少代码的错误，我觉得必要的复审是应该的，但是像文中如此的复审实在是太多浪费时间了，尽管后文有说了很多避免陷入浪费时间僵局的方法，但是我觉得在实际操作中一定会或多或少的陷入不断的开会，开发人员在一个简单的地方浪费非常多的时间导致项目的进展非常的缓慢，其花费的时间可能比文中所说的可能出现的危机所花费的时间花的多得多。
第十七章：
问题：
我对第十七章这段有疑问
我不清楚这里的功高震主是什么意思呢，是说想取代领导的位置吗，但是如果是一个团队的话，不是本来就该能者领导吗，如果是做的太好了，不听领导的规划，那又怎么称得上业绩很好呢？
《构建之法》第四章读后感
问题1：我对于书中的一段有些疑问，这段书中说，不要注释程序是怎么工作的，而要让程序本身来说明这个问题。我认为比较简单的代码确实不需要解释程序是怎么工作的，但是有时候为了两个人更好的配合，对于较负责代码... 查看详情
构建之法第四章读后感
从实际软件开发的各个阶段出发，详细地分析了软件工程的各个环节，如：需求分析、设计实现、用户体验、软件测试已经最后的发布等等。以前写软件或者说程序，就只是写程序，最多会考虑到数据结构的知识，很少会用到软... 查看详情
《构建之法》第四章第十七章读后感
第四章问题：如果另一个合作者不合作的话，我是应该选择脱离这个团队还是去催他工作？ 本章讲了许多关于结对编程的内容，文中写了结对编程的分工问题，结对过程中会出现的问题以及结对合作的不同阶段。 正常来... 查看详情
构建之法第四篇读后感
只有先清楚自己的用户是怎样的，才能编出一个好软件，而其中，典型用户和典型场景的分析非常重要。用例也是很常用的需求分析工具，包括以下四个基本要素：标题，角色，主要成功场景，扩展场景等。而使用用例的原则主... 查看详情
构建之法读后感第四篇
使用软件的人叫做用户。那么，想要编出一个好软件，就必须要清楚的知道自己的用户是什么样的。于是乎，典型用户和典型场景的分析就变得尤为重要。那么，怎么定义典型用户呢？定义典型用户的模板可以包括以下内容... 查看详情
构建之法读后感part4
本周读完了构建之法的第四章，本章内容主要是讲“两人合作”，有一句话众所周知“三个臭皮匠赛过诸葛亮”，无论是从事什么活动或者工作，合作的力量总是1+1>2软件开发的过程是复杂的，显然的一个人的智慧是不够的，... 查看详情
构建之法读后感01
第四章阅读笔记我过去的做法写代码时不写注释，变量命名为a,b,c，如果if，for语句后只有一个语句，不用大括号包起来。之前这么做只要运行成功就行，不管别人能不能看懂这么做的缺点进入团队以后，队友看自己的程序会一... 查看详情
《构建之法》第4章第17章读后感
第四章 原文： 4.3.2：goto函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto。 问题： 是否什么地方都可以使用goto语句，为什么... 查看详情
《构建之法》第第十七章读后感(代码片段)
第四章 在这一章最后一页“让独占一样还有一个好处：一眼就能看出是否有多余的代码行，还有些情况下是致命的错误”给出的参考链接http://lpar.ath0.com/2014/02/23/learning-from-apples-goto-fail/，我还是没明白的致命错误在... 查看详情
构建之法第第五章读后感
第四第五章着重讲了合作的重要性，从两人合作到团队合作，编程开发都不是一件容易的事情，要注意许多要点。代码书写的规范。你写的代码不仅仅是给机器看的，给你看的，也是给其他人看的，是给合作的队友看的，在写的... 查看详情
《构建之法》读后感
写《构建之法》读后感的想法，其来已久，一直未能完成。拖延症爆发的原因大概有二，一是感觉吸收的不够丰富而无法反刍，二是选择不好读后感切入的角度。《构建之法》2014年出的第一版，买到书时已是开学季，想要调整... 查看详情
构建之法粗读读后感_1
...先思考，人的思维不是固定的，创造总在思考中萌发的；第四章，两人合作，两人合作的不同阶段和技巧该如何处理和进行；第五章，团队和流程，主要讲团队和非团队的区别，以及软件团队的模式，开发流程。就目前看来前五... 查看详情
构建之法的读后感
构建之法的读后感 七月份读完了构建之法这本书，粗读，基本了解了软件工程这个专业的工作，就业，和前景。目前有如下体会（构建之法这本书正如前言所介绍，适合软件工程的任何阶段去读，我现在只阅读了一遍，还会... 查看详情
《构建之法》读后感
《构建之法》读后感 通过对本书的阅读首先让我了解了软件的组成：软件=软件工程+程序，对软件工程的意义有了更深入的理解。软件工程是在为了解决软件危机的背景下提出的，它使软件从需求分析到代码设计再到软... 查看详情
《构建之法》读后感02
通过阅读这一章的构建之法，让我感受最深的一个道理就是一个真正的软件是由多人完成的。虽然个人能力非常重要，但是团队之间的配合却是更为重要。而我们现在最缺少的就是这种团队之间的沟通交流。因为我们从... 查看详情
构建之法读后感
通过几天的阅读，初步对《构建之法》这本书有了初步的了解。最深的一点感受是这本书将开发过程中遇到的现实问题描绘的很好，很有幽默感。但是对一些专业术语不是很明白。比如开始都不知道最基本的瀑布模... 查看详情
《构建之法》读后感
这学期的软件测试课程多加了《构建之法》这本书，这学期利用自己的课余时间学了这本书，感觉受益匪浅。对于这本书可以简单地有两个词语来概括：“专业”、“接地气”。这本书的开头就是给我解释什么事软件、什么是软... 查看详情
构建之法六章读后感
在本周我主要学习了构建之法的第五章和第六章，第五章主要讲述团队和流程，第六章主要讲述敏捷流程；软件团队的模式有：主治医师模式、明星模式、社区模式、业余剧团模式、秘密团队、特工团队、交响乐团模式、爵士乐... 查看详情