读《构建之法》5—7章

第五章 第三节

书本上给我们介绍了瀑布模型、生鱼片模型、子瀑布模型和RUP,实际上目前的公司做出一个软件都是以渐进交付的流程不断循环的,最后才决定最终版本的吗?

第六章 第二节

本章节要是谈论敏捷的流程、敏捷流程的问题和解法、敏捷的团队、敏捷的总结以及敏捷的故事,知道了敏捷能极大的提高了团队的能动性。在软件开发项目中敏捷的流程安排到每个团队的成员,但是对于每个团队的成员不一定是合适的,出现这种情况应该怎么办?什么时候使用敏捷才是最适合的?

第七章 第五节

在第五章中讲了开发人员和测试人员会产生一种对立的情绪,这种对立的情绪短时间内能刺激成员的工作热情,而长远的话会有害的。在现实的公司中,如果开发人员和测试人员产生了对立的情绪,应该如何解决?如何减少这种对立的情绪对他们带来的影响?

读后感受:

通过读这些章节,让我了解到了开发流程、敏捷流程以及MSF等知识,不但丰富了我的知识,还让我明白了在一个团队中,团队中的每个成员都应该各司其职,对项目共同负责,更重要的是每个成员的目标必须是一致的,这样我们才能把一个项目做得最好,否则就算你的项目做出来了,你的项目都是烂不可言的(如书本上下围棋的例子),每个成员不能以旁观者的心态来对待项目,必须要以负责任的态度来对待它。一个团队的成败就决定于你团队的成员是否对你这个团队负责。

时间: 2024-11-09 18:40:16

读《构建之法》5—7章的相关文章

读构建之法 第三章:软件工程师的成长

本章理论和知识点:评价软件工程师水平的主要方法 软件工程把相关的技术和过程统一到一个体系中,叫"软件开发流程",软件开发流程的目的是为了提高软件开发.运营.维护的效率,以及提升用户满意度.软件的可靠性和可维护性. 软件开发流程不光指团队的流程,还包括个人开发流程,因为软件团队是由个人组成的.个人在团队中也有独立的流程.把每个人的工作有序地组织起来,就是团队的流程."有序",并不是"无争论".在大部分成功的软件团队模型中,各个角色有不同意见的冲突在

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

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

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

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

读构建之法 第五章:团队和流程

团队有一致的集体目标,团队要一起完成这目标.一个团队的成员不一定要同时工作,例如接力赛跑. 团队成员有各自的分工,互相依赖合作,共同完成任务. 软件团队有各种形式,适用于不同的人员和需求.基于直觉形成的团队模式未必是最合适的.软件团队的模式,最初是混沌的一窝蜂形式:一群人开始写代码,希望能写出好软件.随着团队的成熟和环境的变化. 团队模式会演变成下面几种模式之一. 1.主治医师模式:有首席程序员,他/她负责处理主要模块的设计和编码,其他成员从各种角度支持他/她的工作(后备程序员.系统管理员.工具

《构建之法》第一章读后随笔

<构建之法>第一章首先提出了“软件=程序+软件工程”的观点,然后介绍了软件开发的不同阶段,最后阐述了软件工程是什么的问题.这让我对软件工程有了新的认识,也对构建之法的重要性有了更为深刻的理解. 其实很多工科的很多道理都是相通的.不光是在软件工程,几乎的所有工程中,当工程规模到达了一定的数量级,就不可能是由一个人的一己之力能够完成的,这就需要相互协作,每个人只能做自己的一部分工作.如何能够让别人理解自己的工作的作用,如何能让每个人的工作都能融入一个系统,这就需要模块化,需要集成,话句话说,就是需

《构建之法》第一章概要及读后心得体会

1551427    钱洪章 首先知道:软件=程序+软件工程 名句:程序=数据结构+算法 提出疑问:"程序"是什么? 这里的程序指的是源程序,就是一行一行的代码. 软件够贱的过程:不仅仅是cc和link命令,一个复杂的软件不但要有合理的软件架构.软件设计与实现,还要有各种文件和数据来描述各个文件之间的依赖关系.编译参数.链接参数,等等. 新名词:源代码管理(配置管理).质量保障.软件测试.需求分析.软件维护.软件生命周期.软件项目的管理.软件的用户体验.商业模式 会得到一个扩展的推论:

读构建之法之感

读构建之法之感,为什么迟迟没有发构建之法这本书的观后感,是因为想要细细的看,为什么老师这么要求我们这么做,为什么要刻意的去发微博,原因都在构建之法的这本书中.构建之法这本书和其它的软件工程的书不同,构建之法这本书讲的清晰有趣,容易理解,不像其它的软件工程的书籍,写的那么的枯燥和乏味,构建之法的每章都有很大的联系,让人逐渐的去深刻的理解.通过构建之法理解并懂得什么是软件工程,软件工程是系统的,有序的,可量化的方法应用到软件的开发,运营和维护中去.希望通过自己的努力以及软件工程的课能够让自己有一个小

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

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

构建之法第四章学习心得

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

2017-2018-1 20179215 《构建之法》第一章总结

<构建之法>第一章总结 1.程序=数据结构+算法. 软件=程序+软件工程 ?客户们对程序员的需求从一个简单的程序,扩展到一个满足各种功能的应用软件,再扩展到一个能保证维修的软件服务程序,在这里指的是源程序,就是一行行的代码.仔细看过去,它们的确是建立在数据结构上的一些算法程序还要对数据进行操作,这些数据有些是静态的(例如软件的图标.提示信息),有些是动态的(例如程序生成的随机数字.程序通过网络下载的数据.用户的文字或语音输入等)但是光有代码和静态数据还是不行,工程师要把它们构建为机器能懂的可执