阅读《构建之法》1-5章有感

第一章  概论

软件工程是什么?

软件工程的核心部分(构建管理、源代码管理、软件设计、软件测试、项目管理)和用户体验、用户界面设计等组成了软件工程,而软件=程序+软件工程。

软件开发过程中的难题有5点: 1、复杂性 2、不可见性 3、易变性 4、服从性 5、非连续性

软件的其他特性:1、有许多不同的程序设计语言、软件工具盒软件开发平台。 2、存在许多不同的软件开发流程。 3、软件团队中存在许多不同的角色。 4、软件通   常可以存储在磁带上,也可以存储在CD、DVD上。

第二章  个人技术和流程

个人技术与流程与软件工程有什么关系?

软件是由多人合作完成的,不同人员的工作相互有依赖关系,所以个人技术是会影响整个软件开发的过程,个人技术主要是软件开发过程中的细节问题。在开发出软  件后,必须要经过测试才算是完成了软件,这就需要一个好的单元测试的标准——1、单元测试应该在最低的功能/参数上验证程序的正确性。 2、单元测试必须由最  熟悉代码的人(程序的作者)来写。 3、单元测试过后,机器状态保持不变。 4、单元测试要快(一个测试的运行时间是几秒钟,而不是几分钟)。 5、单元测试应该产生可重复、一致的结果。 6、独立性-单元测试的运行/通过/失败/不依赖于别的测试,可以人为构造数据,以保持单元测试的独立性。 7、单元测试应该覆盖所有代码路径。 8、单元测试应该集成到自动测试的框架中。 9、单元测试必须和产品代码一起保存和维护。

第三章  软件工程师的成长

初级软件工程师的成长:

1、积累软件开发相关的知识,提升技术技能(如对具体技术的掌握,动手能力)。例如:对Java、C/C++、C#的掌握,诊断/提高效能的技术,对设备驱动程序(Device Drive)、内核调试器(Kernel Debugger)的掌握;对于某一开发平台的掌握.

2、积累问题领域的知识和经验

第一点和第二点都可以再很多简历上都可以看到,也可以比较容易地检测出来。随着经验的增长,一个工程师可以掌握更广泛、更深入的技术和问题领域的知识。

3、对通用的软件设计思想和软件工程思想的理解。

4、提升职业技能(区别于技术技能)

职业技能包括:自我管理的能力,表达和交流的能力,与人合作的能力,按质按量完成任务的执行力,这些能力在IT行业和其他行业都很重要。

5、实际成果

绝大部分软件工程师的工作成果都是可以公开的,你参与的产品用户评价如何,市场占有率如何,对用户有多大价值?你在其中起了什么作用?行胜于言,这些实际的工作成果,是最重要的评价标准。

软件工程师的职业发展:—考级之路—Steve McConnell版本—大公司版本—自我评估

第四章  两人合作

  结对编程是什么?

结对编程技术是一个非常简单和直观的概念,能达到事半功倍的工作效果。但是,人与人之间的合作不是一件简单的事情——尤其当人们都早已习惯了独自工作的时候。实施结对编程技术将给软件项目的开发工作带来好处,只是这些好处必须经过缜密的思考和计划才能真正体现出来。而另一方面,两个有经验的人可能会发现配对编程里没有什么技能的转移,但是让他们在不同的抽象层次解决同一个问题会让他们更快地找到解决方案,而且错误更少。两个程序员具有相同的缺点和盲点的可能性很小,所以当我们采用结对编程的时候会获得一个强大的解决方案。而这个解决方案恰恰是其它软件工程方法学中所没有的。在我们平时的编程当中,如果遇到一个非常难解决的问题(困难到对该项目产生厌烦的态度),那么你势必会希望录求帮助,无论是从信息量庞大的网上,还是从身边的技术大师那里,你都会努力去解决(前提是你有对计算机知识的热爱)。这个时候不妨采用结对编程试一下,其它的不说,可能感觉就不同。其实结对编程坐起来很简单也很有趣,找个水平差的不太远的程序员和自己配成一对。只用一台计算机,大家选一个人坐在键盘前面负责输入,另一个人坐在后面口述。两个人要不断的交流,频率不应低于一分钟一次。整个的设计思想由后面只动口不动手的人主导,而由操键盘的人做实现。由于人的思维速度是快于输入代码的速度的。那么观看的人可以有空闲的时间做额外的思考,观察代码写的有没有问题,结构有没有问题。关于结对编程,发现了一些新的受益之处。首先,它可以促进参与项目的程序员自身的提高,一对程序员工作的时候,水平较低的一方会潜移默化地受水平略高的程序员影响,学到一些新的东西。而水平高的一方同样因为不断地把自己的想法说出来而整理了自己的思路。

第五章  团队和流程

  团队和流程的作用?

软件团队的形式

软件团队有各种形式, 适用于不同的人员和需求。软件团队的形式, 最初是混沌的一窝蜂形式: 一群人开始写代码, 希望能写好好软件。随着团队的成熟和坏境的变化, 团队模式会演变成下面的几种形式之一:一窝蜂模式 (chaos team);主治医师模式: (Chief-Programmer Team, surgical team);明星模式(Super-star model);社区模式(Community Model);业余剧团模式(Amateur Theater Team);秘密团队(skunk work team);特工(SWAT) 团队;交响乐团模式(Orchestra);爵士乐模式(Jazz Band);功能团队模式(feature team);官僚模式(bureaucratic model)。

我们在开发,运营, 维护软件的过程中有很多技术, 做法, 习惯, 和思想。软件工程把这些相关的技术和过程统一到一个体系中, 叫“软件开发流程”,软件开发流程的目的是为了提高软件开发, 运营, 维护的效率;以及用户满意度, 可靠性,和软件的可维护性。瀑布模型(waterfall model)--软件工程还是年幼的行业的时候, 它从别的成熟行业(硬件设计, 建筑工程) 借用了不少经验和模型。在那些”硬” 的行业中, 产品大多遵循[分析-> 设计-> 实现(制造) -> 销售 -> 维护] 这个流程。 由于在硬行业中产品一旦大规模生产, 要再返回去修改时非常困难, 甚至不可能的。因此这个模型描述了单向的, 不可逆的生产过程。生鱼片模型(各相邻模块像生鱼片那样部分重叠)大瀑布带着小瀑布,为了解决不同子系统之间进度不一, 技术要求迥异, 需要区别对待的问题。有人引入了子瀑布模型。

时间: 2024-11-08 04:34:34

阅读《构建之法》1-5章有感的相关文章

阅读《构建之法》6-7章有感

第六章  敏捷流程 敏捷开发宣言——个体和交互 胜过 过程和工具可以工作的软件 胜过 面面俱到的文档客户合作 胜过 合同谈判响应变化 胜过 遵循计划 以上的宣言比较抽象,基于该理念,以下是ThoughtsWork咨询公司的推崇的n个敏捷开发实践:Iteration迭代开发.可以工作的软件胜过面面俱到的文档.因此,敏捷开发提倡将一个完整的软件版本划分为多个迭代,每个迭代实现不同的特性.重大的.优先级高的特性优先实现,风险高的特性优先实现.在项目的早期就将软件的原型开发出来,并基于这个原型在后续的迭

读《构建之法》13--17章有感

第十三章讲的是软件测试,其包括功能测试和非功能测试,测试方法有单元测试,代码覆盖率测试,构建验证测试,验收测试“探索式”的测试,回归测试场景.集成.系统测试,伙伴测试,效能测试,压力测试,内部/外部公开测试,易用性测试 第十四章讲的是质量保障,软件的质量=程序的质量+软件工程的质量 第十五章讲的是软件的稳定和发布的阶段,在稳定阶段的初期,团队只需决定修复那些缺陷,然后团队成员进行代码的修改与测试,发布 阶段后,需回顾过程以及学到了什么 地十六章讲的是IT行业的创新,一个好的想法会带来伟大的创新,

阅读构建之法第六章

      这一小节中有一个图表,对比了敏捷(Agile).计划驱动(Plan-driven).形式化的开发方法(Formal Method)的适用范围.里面提到的形式化的开发方法,其基本步骤是怎样的呢?为什么它能有极高的可靠性呢?下面是一些关于形式化方法特点的说明,从中可以看出它能力的缘由. 形式化方法建立在严格的数学基础上,其目标是希望能使系统具有较高的可信度和正确性,并能使系统具有良好的结构,使其易维护,关键是能较好地满足用户需求."形式化方法"一词虽然一直被广泛地应用,但在不同

第一次阅读构建之法

    第一次阅读构建之法,把以前很多门课的知识点联系到了一起.      软件=程序+软件工程.我认为这是对软件的一种及其精炼的解释.程序即是指一行行代码,软件工程则包含了各种软件开发活动,包括构建管理.源代码管理.软件设计.软件测试.项目管理等等,是把系统的.有序的.可量化的方法应用到软件的开发.运营和维护上的过程.      从一个简单的程序,扩展到一个满足各种功能的应用软件,再扩展到一个能保证服务质量的软件服务.源程序是建立在数据结构上的一些算法.构建不仅仅是CC和link命令,一个复杂

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

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

构建之法第六章学习心得

这周我学习了构建之法第六章敏捷流程,本章主要介绍了敏捷流程及其原则,Backlog.Burn-down.Sprint.Scrum方法论.以及什么时候选择敏捷的开发方法,什么时候选择其他方法..敏捷开发的原则是尽早并持续地交付有价值的软件以满足顾客需求敏捷流程欢迎需求的变化,并利用这种变化来提高用户的竞争优势经常发布可用的软件,发布间隔可以从几周到几个月,能短则短业务人员和开发人员在项目开发过程中应该每天共同工作以有进取心的人为项目核心,充分支持信任他们无论团队内外,面对面的交流始终是最有效的沟通

《构建之法》第一章读书笔记

工程有了一个初步的了解.介绍了软件工程里的一些基本概念,软件开发的几个阶段.软件工程的特殊性.目标以及软件工程与计算机科学之间的联系与区别.    软件工程作为一门新兴的学科,是连接计算机硬件和传统机械工程的一个桥梁.起先,我所认为的软件工程单纯的只是编程,通过算法实现正确的输出而已.但在构建之法的第一章中,我认识到会写程序只是一个合格的软件工程师最基本的素质.一个完整的项目,应该在需求分析,软件构架设计.代码实现.程序测试.软件发布运营及维护每个阶段都尽职尽责,并结合用户体验去完善软件的每一个

构建之法第四章学习心得

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

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

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