《构建之法》阅读后不懂的5个问题

1、这些是我的五个问题......

1) 上学期一门课的老师跟我们说,代码的注释和规范很重要,因为别人会来维护你的代码。可是又有人说 代码维护是完全没有必要的事情,就是不如推翻了重写。

到底哪个是对的。。。。

2)团队里面,会不会因为大家都有自己的想法,然后迟迟定不下来不能统一什么的,反而效率更低呢?

3)怎么样的一个软件才是一个好的软件?

4)如何衡量开发成本和收益啊

5)客户的要求是第一位的?即便会导致错误结果什么的呢。。。。

2、软件和软件工程的出现

软件一词在: 1958 年Turkey在论文“The Teaching of Concrete Mathematics”中提出。

软件工程一词是Margaret Hamilton在NASA设计阿波罗号电脑上的软件时提出的新名词。

3.代码版本管理软件

1)Git

Git是一款免费、开源的分布式版本控制系统,用于敏捷高效地处理任何或小或大的项目。Git是一个开源的分布式版本控制系统,用以有效、高速的处理从很小到非常大的项目版本管理。

优点:适合分布式开发,强调个体。公共服务器压力和数据量都不会太大。速度快、灵活。任意两个开发者之间可以很容易的解决冲突。离线工作。

缺点:资料少(起码中文资料很少)。学习周期相对而言比较长。不符合常规思维。代码保密性差,一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。

2)VSS

VSS 采用标准的 windows 操作界面,只要对微软的产品熟悉,就能很快上手。 VSS 的安装和配置非常简单,对于该产品,不需要外部的培训(可以为公司省去一笔不菲的费用)。只要参考微软完备的随机文档,就可以很快的用到实际的工程当中。 VSS 的配置管理的功能比较基本,提供文件的版本跟踪功能,对于 build 和基线的管理, VSS 的打标签的功能可以提供支持。 VSS 提供 share (共享 ) 、 branch( 分支)和合并( merge) 的功能,对于团队的开发进行支持。 VSS 不提供对流程的管理功能,如对变更的流程进行控制。 VSS 不能提供对异地团队开发的支持。此外 VSS 只能在 windows 平台上运行,不能运行在其他操作系统上。VSS 的安全性不高,对于 VSS 的用户,可以在文件夹上设置不可读,可读,可读 / 写 , 可完全控制四级权限。但由于 VSS 的文件夹是要完全共享给用户后,用户才能进入,所以用户对 VSS 的文件夹都可以删除。这一点也是 VSS 的一个比较大的缺点。VSS 没有采用对许可证进行收费的方式,只要安装了 VSS ,对用户的数目是没有限制的。

时间: 2024-11-05 13:42:02

《构建之法》阅读后不懂的5个问题的相关文章

构建之法阅读笔记三—结对编程

构建之法阅读笔记三——结对编程 何谓结对编程,结对编程就是程序员肩并肩,平等的,互补的进行开发工作,他们使用同一台电脑,编写同样的程序,一起分析,一起设计,一块交流想法. 然而我以前却并不是这样做的,我以前喜欢在没人打扰的环境下写代码,我觉得有人在我身边看着,会影响我的思路,还有我个人自尊心比较强,不太喜欢被人指指点点,所以每次都是,我写完代码之后,自己先找自己的bug,每当自己实在找不到之后,才会请教大神,但是有时候可能由于自己的能力不足,往往一个很简单的问题,我自己发现就会花费很久的时间,让

构建之法阅读笔记四—团队开发

构建之法阅读笔记—团队开发 软件开发过程中有团队和非团队之分.其区别就在于目标利益的不同,团队中每个人的目标是一致的.共同的,会根据实际情况给每个人分配不同的任务,不会计较个人利益的得失.非团队每个人的目标都是不同的,大家都为自己的利益而奋斗. 在阅读了构建之法后,我了解到团队开发有以下的特点:1.团队开发有一致的集体目标,团队要完成这个目标.一个团队成员不一定要同时工作.2.团队成员有各自的分工,互相依赖合作,共同完成任务.还有完成一个项目开发的工作流有业务建模,需求,分析和设计,实现,测试,

构建之法阅读笔记6--敏捷开发2

构建之法阅读笔记—敏捷开发2 敏捷开发并不是一门技术,它是一种开发方法,也就是一种软件开发的流程,它会指导我们用规定的环节去一步一步完成项目的开发:而这种开发方式的主要驱动核心是人:它采用的是迭代式开发:敏捷开发并不是瀑布开发模型,它是以文档为驱动的,为什么呢?因为在瀑布的整个开发过程中,要写大量的文档,把需求文档写出来后,开发人员都是根据文档进行开发的,一切以文档为依据:而敏捷开发它只写有必要的文档,或尽量少写文档,敏捷开发注重的是人与人之间,面对面的交流,所以它强调以人为核心.而所谓的迭代开

构建之法阅读计划

1.本学期我打算阅读关于软件工程的三本书. 在第1-4周先把构建之法阅读完成 5-9周把人月神话阅读完成 10-16周重新寻找新的书刊阅读 2.速览构建之法中的问题 (1).在之后的团体项目中,我们几人如何分配任务,分配任务之后,如果有一些比如我编程能力缺乏,如何才能真正使这个团队最后的软件质量得到保证 (2).还有如果因为分配之后你学习到只有一部分的知识,另一部分如何学习熟练 (3).我们学习的知识只是基础,到了一些企业中,所用的软件不同,会不会白学. (4).在学校的时候用什么样的团队模式最

03构建之法阅读笔记之一

构建之法阅读笔记03 遇到问题总是想弄清楚所有细节.所有依赖关系之后再动手,想的太多,没法前进,分析的就会出现错乱,或者直接动手,慢慢发现偏离的一开始的轨道,忘记了目标,这样就会产生"分析麻痹"和"不分主次,想解决所有问题",以后遇到问题应该时刻记住自己的目标,在解决问题的时候不断提醒自己,应该如何思考.越早对自己有一个清晰的定位,对自己越好,很多人只是把软件工程师当成一个工作,当成一个能挣钱养家的营生,而我想把它的当成自己投身的事业,把软件项目相关的目标作为长期的

作业3 阅读《构建之法》后的收获与感悟

读完<构建之法>的1-5章后我才发现这本书把我们软件工程诠释得太好了,有很多精辟的思想和建议在这里,让我看完之后感触颇深,虽然我才看完了前五章,但是我的激情已被点燃,我发现我已经深深爱上这本书了,强烈地好奇心迫使我快点往下看了.可我还是先暂时压制住了我的好奇心,先把读后感写完再看. 第一章:这章主要是讲软件工程的概论,讲述了软件工程的发展史还有起源及其软件工程的特性.这使我开阔了我的视野.让我了解到了软件工程的由来也不是容易的,它经历了好几个阶段.这章让我比较感兴趣的是讲述了软件工程的开发和维

构建之法阅读笔记05

2017.5.20 今天阅读的是<构建之法>第8章需求分析的阅读笔记,我们如果要开始做一个软件,最先要进行的就是需求分析,我们应该充分的了解我们这个软件是否具有前景,我们为用户提供的服务是不是用户所需要的,这一章详细的叙述了如何进行需求分析. 首先是获取和引导需求,我们应该找到软件的利益相关者,了解挖掘他们对软件的需求,引导他们表达出真实的需求.然后分析和定义需求,对各个方面的需求进行规整,定义需求内涵,从各个角度将需求量化,然后估计实现这些需求所需要的时间和资源,确定各个需求的优先级.紧接着

构建之法阅读笔记三

今天阅读了构建之法第四章,对我最深的感触就是代码规范,对于一个软件工程师来说,编程是一项基本技能,程序编的好一半来自于代码的规范:就算你学的算法再好,编程能力再强,代码不规范也没有任何意义.当阅读者拿到你的代码时一头雾水,完全看不懂,这样的代码对于后期的维护和bug的寻找难上加难,或者是对于后来的初学者来说,也是去了教育意义.所以在我们日常的编程过程中要养成代码规范的习惯,习而久之,这样的习惯会一直伴随我们编程整个过程. 还有就是代码复审,我一开始也想不明白,代码为什么要复审呢,写完代码得到执行

构建之法--阅读笔记二

阅读笔记二—代码规范 代码的风格的原则就是:简明,易读,无二义性.我虽然是计算机系的学生,但是我以前却没有秉着这个原则来编写代码,现在阅读了构建之法后,我明白了如何让你的代码变得简明,更容易理解. 代码在编写的过程中注意: 用Tab键缩进 要注意行宽,最多限定100字符的行宽 在复杂的条件表达式中,用括号清楚地表达逻辑优先级 要注意断行与空白的{ }行,有明确的“{”和“}”来判断程序的结构 不要把过多的语句放在同一行上 对变量命名要有实际的意义 用下划线来分隔变量名字中的作用域标注和变量的语义

软件工程-构建之法 阅读笔记

在我正式开始阅读这本书之前,我对于软件工程这个词汇的概念还是模糊的,认为它只是停留在是一门学科,一个专业,或者是一大堆硬生生的理论知识,然而当我读完构建之法这本书的推荐序和第一,第二版前言开始,我就深刻意识到我之前对于软件工程的肤浅认识是多么错误. 我看书一般喜欢从从书的封面开始看起,或许这也是大多数人看书的习惯,·在本书的封面素描着一副鲁班锁,刚开始让人感觉有点奇怪,明明是一本讲软件工程的书,为什么要用鲁班锁做为封面图案呢?原来玄机深藏于鲁班锁的内部,这鲁班锁从外部看,是严丝合缝的十字立方体,