构建之法读后感----第1章 绪论

首先,文章对于程序、用户需求、工程等等概念用了阿超给儿子编写的一个出题程序来分别解释了个中的含义,尤其是程序和工程的区别,程序大概就是用很多语言或工具编写的一个简单能实现目标要求的一行行代码,而工程就是在这个程序的基础上不断满足用户的需求、修复程序的bug、提供后续维护等服务。

需求分析:梳理需求,逐步展开后续工作,如设计(软件架构)、实现(写数据结构和算法),测试,发布软件

软件=程序+软件工程(软件企业=软件+商业模式)

软将工程的核心部分:构建管理、源代码管理、软件设计、软件测试、项目管理(广义上还有用户体验、用户界面设计等



然后对于软件开发的不同阶段有一个详细而有趣的举例

1.玩具阶段

通过“设计/制造纸飞机”的例子说明所有的事物都或多或少都体现了某些基本理论

2.业余爱好阶段

讲述了梦想和爱好对于人类社会能有多大的贡献(爱好者的尝试:气球+沙滩椅升空)

3.探索阶段

持续探索实践对于实现梦想的重要性,以及先行者伟大的钻研精神(莱特兄弟飞行)

4.成熟的产业阶段

在先人的基础上不断完善,成为一个产业(飞机制造业)



接着阐述了软件工程的定义

其中比较令人深思的部分就是软件开发过程中的五点难题

1.复杂性(Complexity)

“软件的各个模块之间有各种显性或隐性的依赖关系,随着系统的成长和模块的增多,这些关系的数量往往以几何级数的速度增长,而理解运用这些复杂性的人并没有太大的变化“,这样意味着虽然现在的软件看起来功能越来越强大,使用也非常便捷,但实际上这种强大是建立在更多的人手和更长的开发时间上的,所以如何解决人力问题是今后快速开发大型复杂问题的重中之重。

2.不可见性(Invisibility)

“软件以机器码的形式高速运行,还可能在几个CPU核上同时运行,工程师是‘看‘’不到自己的源代码如何具体地在用户的机器上被执行的”,就是程序总会以自己无法预知的方式执行,当程序出错时,几乎无法完整重现程序到底出了什么问题,这对于bug的修复实在是有点无力。

3.易变性(Changeability)

“正确地修改软件是一件很困难的事情”,这点在我们亲自编程的过程中已经有了深刻地了解。。。

4.服从性(Conformity)

“软件不能独立存在,它总要运行在硬件上面,它要服从系统中其他组成部分的要求,它还要服从用户的要求、行业系统的要求”,意味着如果想要广为发布一个程序,除了程序本身的正确性,还要考虑很多外在因素才能保证程序的良好运行。

5.非连续性(Discontinuity)

“有时输入上很小的变化,会引起输出上极大的变化”,这需要从设计上着手考虑如何让用户更好地熟悉一个程序的操作,不能让用户对自己操作的结果摸不着头脑。



构建之法读后感----第1章 绪论

时间: 2024-10-02 11:36:32

构建之法读后感----第1章 绪论的相关文章

阅读构建之法读后感第三章

养成一个优秀的程序员必须做到的: 1.代码规范 首先我们需要了解的是我们的代码不只是给机器看的主要还是给人看的,那么我们就需要将我们的代码写的清清楚楚. 代码风格规范:主要是文字上的规范,看似表面文章实际上非常重要.代码风格的原则就是简明,易读,无二义性. 1.缩进,使用tab键,4个空格的距离看着正好. 2.行宽,必须限制行宽. 3.括号,括号清楚的表示逻辑优先级. 4.断行与空白{}行. 5.分行,不要将多条语句放在同一行. 6.命名,必须分清楚类,变量,关键字的命名方式. 7.下划线,用来

《构建之法》第四章读后感--软件工程

<构建之法>第四章读后感--两人合作 1.代码风格很重要,因为良好的代码风格,有益于两人的合作甚至多人的合作. 个人认为 : 良好的代码风格的培养就是 多去阅读别人的优秀代码 ,用于提高并且培养自己的代码风格. 2.关于结对编程的重要性 2.1 结对编程能提高设计质量与代码质量 2.2 结对有益于学习交流 3.如何结对编程 3.1 主动参与讨论,提出设计方案或者问题的解决方案 4.代码的复审 复审可以提高代码质量,优化项目性能.

构建之法五、六章读后感

在本周我主要学习了构建之法的第五章和第六章,第五章主要讲述团队和流程,第六章主要讲述敏捷流程: 软件团队的模式有:主治医师模式.明星模式.社区模式.业余剧团模式.秘密团队.特工团队.交响乐团模式.爵士乐模式.功能团队模式.官僚模式: 开发流程包括:写了再改模式.瀑布模型.瀑布模型的变形(生鱼片模型.大瀑布带着小瀑布): Rational Unified Process统一流程(RUP):包括业务建模.需求.分析和设计.实现.测试.部署.配置和变更管理.项目管理.环境: RUP的四个阶段包括:初始

《构建之法》第十七章读后感

通过阅读<构建之法>第十七章,不能说对我造成了什么深远的影响,但是还是感触颇深: 第一,工作分配的重要性,说道工作分配,不得不说我们个小组的组长们,组长不仅仅是一个团队的领导者,更是这个团队的灵魂.它不仅需要了解随时掌握各组员的动向,更重要的是,他需要了解各组员的能力,然后根据个人的能力,然后再去非陪相应的任务,只要这样才能做到“物尽其用”,才能更好的完成我们的项目,有时甚者能更创造出以外的效果,达到更完美的状态.这不仅是组长的能力  其实其无时无刻也体现着我们这个小组的团结力和创造力.当初选

构建之法读后感part7

这个星期我看到了构建之法的第七章,第七章介绍了微软推荐的软件开发方法MSF. MSF的最大特性是商业化,并一直体现在项目的实施过程中.所谓商业化意味着客户的商业利益.客户 投入多少,得到多少回报,客户要用到哪些最新的技术,最后如何把项目计划变成产品直至产生效益, 等等,这些都是MSF要考虑的问题.我认为MSF的基本原则,不仅符和软件开发流程,而且也也可以应 用到平时生活和学习.如学习所有的经验,学习他人经验及自己的过去的经验,反思错误,才会获取到知识.

构建之法读后感part4

本周读完了构建之法的第四章,本章内容主要是讲"两人合作",有一句话众所周知"三个臭皮匠赛过诸葛亮",无论是从事什么活动或者工作,合作的力量总是1+1>2 软件开发的过程是复杂的,显然的一个人的智慧是不够的,遇到问题一起解决,工作一起分担能使开发的效率提高很多.以后到公司团队工作,合作很大程度上实现优势互补,比如说有人擅长界面设计,有人擅长实现功能,这样的合作能减少工作量提高整个开发效率.有些人技术很好,可是在沟通这方面十分欠缺,这是很不利于合作的,在项目的开发

《构建之法》第三章学习心得

这周我学习了<构建之法>第三章,讲述了软件工程师的成长.软件系统的绝大部分模块都是由个人开发或维护的.在软件工程的术语中,这些单个的成员叫做Individ-ual Contributor(IC).IC在团队中的流程是怎么样的呢?以开发人员为例,流程如下. 1.通过交流.实验.快速原型等方法,理解问题.需求或任务 2.提出多种解决办法并估计工作量 3.其中包括寻找以前的解决方案,因为很多工作是重复性的 与相关角色交流解决问题的提案,决定一个可行的方案 执行,把想法变成实际中能工作的代码,同时验证

阅读《构建之法》第四章感想

课下阅读<构建之法>第四章,自己有以下一些感想. 1.我们写的代码最终都是要给人看的,所以代码规范化是一个优秀编程员必备的良好习惯,而且若是在团队里工作,那么代码规范更加重要.编程人员要遵循的代码风格的原则是:简明,易读,无二义性.以后自己要养成规范代码的习惯. 2.复审也是不可缺少的一个步骤,软件工程中最基本的复审手段就是同伴复审,找熟悉代码,有经验的人来进行复审. 3.当今时代,一个人能发挥的力量越来越小,团队的力量日渐重要,因此,如何合作,很关键.两个人合作,如何影响对方,要因人而异,因

《构建之法》第四章

<构建之法>第四章讲的是两个人的合作.结对编程.结对编程往往只需花费大约一半的时间就能编写出质量更高的代码. 代码规范方面,在给函数或者类取名的时候要严谨,不能写一些没意义的名称:在一些代码后面可以加些注释来说明此行代码的作用,在复审方面,我觉得自我复审时最好的,刚写好的代码脑袋里印象深刻,能很好的解决逻辑错误和算法错误. 结对编程方面,书中生动形象的说明了开发者的搭档关系,在结对的时候怎么分配任务,怎么通力合作.互相帮助,在两人的合作过程中,怎么磨合.互相提高水平,在遇到问题或者矛盾的时候,