浅读《构建之法》有感

　　老实说，一本书摆在面前，实在是不愿意翻看它，不全是因为它厚，还有一部分原因是没找到成就感。但是老师布置了任务，开学第一次作业就一塌糊涂，好像很说不过去。

　　于是抱着这样的想法翻看了第一章。最直观的的感受就是，虽然我我不能够完全看懂书里所讲的内容，但书中的条理非常令人震撼，能让我明显地感受到作者强大的梳理能力，就像什么复杂的事情经他处理后都能迅速分门别类，然后对这件事进行合理的资源分配。

　　

　　《软件工程》这门课对于我来说的确是一个挑战。尽管本科读了四年计算机专业，但实质是读了四年游戏专业，吃喝专业。所以对《软件工程》这门课的期待没有太高，就是做一名学生。做学生该做的事，想学生该想的问题。很期待以后能按时完成作业，别再做一个只会想的菜鸟。

　　读过书后有一个问题就是，我能不能实现从“0“到“1”的突破。Fighting！

　　

　　

时间： 2024-11-05 16:37:21

浅读《构建之法》有感的相关文章

浅读<<构建之法>>有感

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

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

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

（第九周）读构建之法有感1

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

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

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

读构建之法有感

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

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

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

（第九周）读构建之法有感2

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

读构建之法之感

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

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

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

对读构建之法后提出的五个问题

读构建之法有以下几点疑惑: 1.如何使自己的开发思维更加敏捷? 2.如何分配好团队里面成员的任务,来达到最好的工作效率? 3.当面临用户的需求和优化后的软件起冲突时,用户的需求一定是最重要的吗?那么用户根本不了解优化的软件的好处,一定强制要求修改怎么办? 4.如何使自己的产品在市场上占有绝对的优势? 5.什么样的软件开发团队要开发什么样的软件才适合敏捷流程?