读《大道至简》第五章

  假如这一次失败了,不要紧,失败一次没什么,没有一个人是永远的赢家,有谁见过没曾打过败仗的将军?人生不能没有教训。有一句话这样说:“跌倒了不必急着站起来,四周找找看有没有可以捡的,再站起来。”我始终认为,重要的是过程,风雨过后不一定要见彩虹,其实能够引起震动的是雷电。那个彩色的光环是瞬间的,真正有意义的是为此努力、为此奋斗的经历。有智慧的人往往能从逆境中总结出宝贵的经验,所以一个人偶尔失败了,只要意志不倒下,有时反而会有意外的收获。所以说失败的过程也是过程。

  瀑布模型是一个项目开发架构,开发过程是通过设计一系列阶段顺序展开的,从系统需求分析开始直到产品发布和维护,每个阶段都会产生循环反馈,因此,如果有信息未被覆盖或者发现了问题,那么最好 “返回”上一个阶段并进行适当的修改,项目开发进程从一个阶段“流动”到下一个阶段,这也是瀑布模型名称的由来。包括软件工程开发、企业项目开发、产品生产以及市场销售等构造瀑布模型。如上面所说,我们做的不是工程,而是过程。换而言之,亦步亦趋是做不好工程的,如果工程可以那样做成的话,只需要瀑布模型就足够了。因此做过程并不是做工工程的精义。当然了,不仅仅是学到一些知识,我们还应该从中学到其他的,有一些感悟存在才能说不浪费了这本书的作者的期望。

  其次,我们做工程不能仅仅是走过场当项目变成了无休止的演出的时候,不论走了多少的过场都没有任何的意义。再者,我们是为消费者提供服务的,因此,实现才是目的。为工程而工程的人都迷失在项目中了。就像开发人员迷失在一个技术的细节中一样。

  再者,过程不是死模型,我们应该试着跳出大师们的身影,再仔细看一下那些所谓的“经典”的过程,不过就是在瀑布模型上的一再变形罢了。但是我们也应该要清楚,过程模型是在已有的工程中总结出来的,也就是说,在某个模型有了名字之前他就已经存在了,就已经被一些团队或者公司创生并使用了。

  而且,我们做任何事多要做到专业,不能画虎不成反类犬,我们所要比较的是骨子里所得所失的东西,而不是架子上的像与不像。同样得失而论,在瀑布模型与其他的模型之间,学习前者不行,可以思考其中的本质;学习后者不行,可以得到文子的架子。过程理论中,本质的东西若能理解透彻,架子还不是随手搬来就可以用的吗!越是简单的东西,往往越是接近于本质。

  最后,工程不是做的,而是组织的。我们总说做工程,好像工程就像是面包馒头一样,有个模子。经历过过程的人都知道,没有那个模子,工程人员也不是那一团面。所以。我们不能做工程,而是在组织工程,组织工程的各个角色,使之分工明确,以便圆满完成。

时间: 2024-12-28 11:20:11

读《大道至简》第五章的相关文章

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

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

构建之法第五章学习

今天我学习了<构建之法>第五章 团队和流程.首先我了解了写了再改模式(Code-and-Fix) 史蒂夫·迈克康奈尔(Steve McConnell)在这里提到了不少开发流程.第一个提到的开发流程.这个流程也有好处,不需要太多其他准备或相关知识,大家上来就写代码,也许就能写出来,写不出来就改,也许能改好.当面临下面的任务时,也许这个方法是有用的.但是,要写一个有实际用户.解决实际需求的软件,这个方法的缺点就太大了. 然后我学习了瀑布模型 当软件行业还在年幼的时期,它从别的成熟行业(硬件设计,建

现代软件工程构建之法 前五章阅读感想&amp;困惑

第一章 第一节 新时代中国的IT产业市场规则不规范,书中提到社会上有个别软件公司的软件一定要卸载别家公司的软件才能运行,我这里感到疑惑---————是不是说如果 一间软件公司他能做出一个像微软操作系统那样的受大众十分喜爱的软件 那么他就可为所欲为 对一些不友好的软件公司进行屏蔽,从而决定了其他公司的生存??? 第二章 第一节 之第二部分 这里说到程序员作为该单元的开发者 必须亲自写开发单元 但如果遇到上头委派的一件又急又大型的项目 那么还要写单元测试?或者不能让别人写? 第三章 第二节 这里说的

构建之法第五章读书心得

这一章我们主要学习了团队和流程.团队简而言之就是开发一个软件工程的团队,那么团队究竟怎样在一起开发这一软件便有了多种多样的方法. 比如所有人都一起做的一窝蜂模式,但这样模式弊端很大,虽然都做了许多工作,但结合起来的成果可能还没有单人做的进度快.慢慢的发展出了一些其他的模式,比如我们在学校中,一个学霸主力,其他人打酱油,但这并不好.之后也出现了明星模式,社区模式等更好的模式 写了再改模式:这种便是我们学生中最为普遍的一种模式.不管代码怎么样,先写出来,甚至连语法错误都没有考究,整体做完后再针对问题

构建之法第五章

本章为团队和流程,主要介绍了典型的软件团队模式和开发流程以及它们的优缺点.TSP.MVP.MBP.RUP 团队:并不是几个人凑到一起就叫团队,称之为团队 团队有共同的特点: 1.团队有一致的集体目标,团队要一起完成目标.一个团队的成员不一定要同时工作, 例如接力赛跑. 2.团队成员有各自的分工,互相依赖合作,共同完成任务. 总结来说,本章继上一章的两人合作,深入讲解,介绍了团队的定义,模式,开发流程等,虽然有多种模式,也有多种开发流程,但这些各有其优缺点,有其适合的情况,所以在进行选择时,应该的

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

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

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

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

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

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

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

1.团队模式和团队的开发模式有什么关系? 答:    首先我来解释一下这两个名词: 我查资料了解了一下,团队模式,更偏向于多人合作的那种,而且我理解的"团队"会是一种多人合作的情况下,长期磨合后的一个组织,他们是相互了解的,是拥有巨大的默契存在的. 对于团队的开发模式我并没有查到具体的解释,但对于开发模式,是有查到几种开发模式,比如瀑布开发模式.快速应用开发模式等等,我们在其他的课上有学过这些模式,所以我在这里认为开发模式是更偏向于后边的"模式"两个字的,更注重方法

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

典型的团队开发模式和流程,完全是新的内容:涉及到更多的术语和有意思的策略性东西 1.团队模式[我比较认可的] 主治医师模式 由首席程序员(相当于首席医生)负责整个工程,周围人员各司其职,配合支持中心人物的工作: [我认为这种模式适合于有着杰出程序工程师的规模略小的团队] 社区模式 我非常心水的linux社区就是最大的成功案例之一. 社区并不意味着"随意",而是有着严格的复审和质量控制 交响乐团模式 [不适用于创新型的项目,反而是对于稳定的.种在执行的项目的效率比较高] 门类齐全,各种任