观构建之法有感

第一章、为我们解释什么是软件,什么是软件工程,读完这章对这些概念有一定的认识这章让我明白,代码不能盲目的敲,好的软件并非两三天,并非一两个人就能赶出来的,需要大家的精诚合作。同时,在编写程序之前,还需要做一系列的分析、设计,要满足客户的需求,后续还要对软件进行测试、维护等。在这之前,我一直觉得能把程序运行,能有正确的结果,那就完成任务了,可这只是整个软件流程的一部分而已。看了邹老师的书,才知道其实创新有很多的方面,除了技术,还有商业思路,差异化等等,这些都给了我很大的感触,作为一名程序员,我们不能将自己的思维局限在这世俗人的眼光里,要跳出这世俗的局限充分发挥人的想象力,这才是一个好的程序员。

第二章、这章引入了“单元测试”的知识,单元测试对一个好的软件起着重要的作用,单元测试应该是准确、快速地保证程序基本模块的准确性,单元测试也有一系列的标准验证其好坏。单元测试必须由最熟悉代码的人来写,最好是在设计的时候就写好单元测试,这样会减少程序问题的出现。另外考核激发团队的团结力,绩效考核是个不太好做的工作,但是还要做,只有这样,团队才能无往不胜

第三章、这章主要是讲个人能力的衡量和以及软件工程师的职业发展。成为软件工程师,首先要学习和积累软件开发相关的知识,不断学习,不断积累,提升技术技能,理解通用的软件设计思想和软件工程思想。学好专业技能以外,还要有一定的自我管理能力、与人合作能力等,看了才知道原来一个好的软件工程师也不是那么简单,想要成功,就要有所付出,有所牺牲,在别人在玩的时候,充实自己的知识,不然你凭什么在人群中脱颖而出,想要成为一个耀眼的人,就必须先把身上的尘檫干净,不是吗?

时间: 2024-07-28 20:15:14

观构建之法有感的相关文章

第五次软件测试作业 读构建之法有感

之前没有什么认真的看完构建之法这本书,最近用了一星期的时间紧赶慢赶的认真的把书看完了,越看越起劲,后悔之前怎么没有早看着一本书,看了邹欣老师写的构建之法,感觉和读其它软件技术方面的书感觉截然不同,邹欣老师的构建之法想要告诉我们的是一种第一线的编程思想,比起平常所学的技术感觉起来更富有实用性,他用了程序员的第一视角来告诉我们软件编程者一思想,从第一章概论的软件工程是什么开始,就给予人一种引人入胜的感觉,给程序员一种深深的代入感,书中不仅有丰富的代码示例,还采用了一种一问一答的方式来解答问题,我想邹

阅读《构建之法有感》

<!--这周四上完杨老师的软件工程第一课后,本来想从往届学长学姐那里淘到二手书,但是市场太火爆竞争太激烈了,昨天我才意识到估计上一届的书是等不到了就在淘宝上下单,借来了同学的书先看着完成这次的作业.--> 通读了邹欣老师的<构建之法>感到这半书跟一般的技术类书籍不同的是,读起来比较轻松,趣味性很强,穿插着范例跟段子,看到有趣的地方我还跟室友分享了.以下是我对于这本书的疑惑之处: 1.第6章敏捷编程中,感觉是需要定义好任务然后按计划衡量是否完成计划,但是后来又说敏捷团队需要自我管理自

(第九周)读构建之法有感1

构建之法第四章:两人合作 在这一章节里面,我才深刻地认识到自己所编写的代码是有多混乱,多么的不规范.编写规范的代码是程序人员良好的习惯.书本里面提到的代码复审以及结对编程都是要合作的,我们曾经也进行过结对训练,能在实践进行中感受到每个人的角色和作用,学习到很多,对于代码复审则是比较陌生.但是在书中还是了解到代码复审的作用是很强大的,非常适合一些中型以上的程序的测试检查.

8th 对软件工程的理解(读构建之法有感)

对于任何一个学计算机的人来说,软件都不陌生,甚至于一个普通的朝九晚五的上班族,他的每日生活工作也都与软件有着密不可分的关系.然而,程序又是如何从一行行指尖留下的代码,机器存储的数据变成快捷高效的软件的呢?这中间我们所经历的一系列过程的总和,我们称之为软件工程. 从本科开始学习计算机,我们就不可避免的接触了形形色色的软件,了解大量的软件开发工具,我那个时候甚至没有软件工程这个概念,只认为,我们所用的软件就是开发工具编译.执行.包装.发布的产物.后来,开设了软件工程这门课程,才开始系统地接受软件工程

读构建之法有感

鉴于当当的配送服务到现在还没有完成,我的构建之法也还迟迟没有到我的手上栖息,所以去网上看了试读,读到了师生关系这一段,觉得深有感触. 鉴于我曾干过两年的高中物理辅导教师,浅谈一下与书中的共鸣吧. 第一种关系.餐馆和食客,因为是辅导教师,所以在我手里补课的学生有一小部分把我们的关系建构成了餐厅和食客的关系. 她交了钱,需要选一个顺眼或者说合得来或者说能共鸣的老师,于是我出现了.接下去,她会在诸多的章节当中选取她认为自己没有掌握的内容让我讲解. 在这种有主见的学生的情况下,我一般多会那人钱财为人消灾

(第九周)读构建之法有感2

第五章:团队与流程 第五章章节里面主要介绍了团队与非团队.软件团队模式以及开发流程以的各自的优缺点以及一些概念.对于现在的我们可能较为熟悉的开发流程是瀑布模型.对于团队模型我比较有兴趣了解的是功能团队模式. 团队有一些共同的特点:有一致的集体目标,成员之间有各自的分工,合作完成任务.团队一开始可能是"一窝蜂模式",都想写出好的软件,但是没有各自的分工,一般不会这种模式不会存活太久.慢慢会演化成其他模式,比如"主治医师模式",本来是不错的模式,但是在学生身上退化为了一

个人项目增加项-读构建之法有感

惰性像一种毒药,吃起来舒服又会甘之如素.最近克服了种种惰性,又开始读起这本我在研究生阶段买的最贵的书,这本书无论如何我都要读完它,要不买回来供着,太不符合她千里迢迢来到我身边的意义.读后感,其实挺难写的,批评改进意见根本说不出,又没有那么多的工程的思想,只能说一说自己的理解及触动自己的知识点. 读这本书最大的感触就是,看目录一点读下去的感觉都没有,又是一本计算机书,有时真不愿意读本专业的书,晦涩难懂,无数个脑细胞需与之斗争,并且总有种看的越多不会的越多的感觉.但是此书,不像以前看的专业书籍,当你

浅读&lt;&lt;构建之法&gt;&gt;有感

第一章感悟: 这章书中主要讲述了什么是软件工程.在此之前,我对于软件工程只是字面上的的理解,无非是程序员通过敲代码,做出一个软件,但是这个软件是属于工程级别的,体积非常庞大.如今了解到,软件在不考虑的用户需求的前提下,不管多么强大的程序都显得毫无意义,用户不会关心这个程序你写了多久,花费了多少心思,用了什么NB的技术实现的,他只想知道,这个软件能帮我做什么.例如:很多杀毒软件在界面上都显得无比的高深,很多选项和按钮,在专业人士看来,这个非常酷炫的程序,架构复杂,但是,用户却不太容易接受,因为打开

读书笔记(构建之法-11.19)

读构建之法有感: 今天在实验室读了构建之法书的第4章-两人合作,书上首先讲代码规范,一个程序员写的代码主要个人看,而在给人看的前提是要代码规范. 对我个人而言,其实看到没有规范的代码是看不下去的,自己曾经也犯过代码不规范的毛病,以后这种毛病要改掉. 下面说说结对编程,结对编程有如下的好处: 1.在开发层次,结对编程能提供很好的设计质量,两个人解决问题的能力更强. 2.对开发人员自身来说,能带来自信. 3.在企业管理层次上,有效的交流可以更好地应对人员的流动. 结对编程可以不断的进行复审,可以避免