关键词：
构建之法的读后感
七月份读完了构建之法这本书，粗读，基本了解了软件工程这个专业的工作，就业，和前景。目前有如下体会（构建之法这本书正如前言所介绍，适合软件工程的任何阶段去读，我现在只阅读了一遍，还会继续地读下去）：
一， 原来，软件工程并不是像我再选专业之前认为的那样，只是一群人在一起敲代码。软件工程的定义是把系统的，有序的，可量化的方法应用到软件的开发，运营和维护上的过程。（构建之法P8），而软件工程这个专业里细分了，软件需求分析，软件设计，软件构建，软件测试，软件维护。以前只是简单的构想，软件只是一个人写完的，在读完了构建之法后，觉得以前的想法很幼稚，软件工程没有个人英雄主义，而是一个团队，一同辛苦努力工作的结果。去写任何一个软件，都要有规范的步骤，分析需求---生成设计文档---设计复审---代码规范---具体设计---具体编码---代码复审---测试。成熟且实用满足需求的软件并不是一蹴而就的，而是一群人的成果。
二， 读完构建之法后，简单了解了软件工程师的就业，和考证，第三章系统讲解了软件工程师的成长之路，引用P59页的图表，SDE初级软件开发工程师（入门。在学校里学到了些技能，尚未在实践中得到充分锻炼）---SDEⅡ中级软件开发工程师（独立。可以写别人交给你的任何东西，不明白时知道去问谁）---Senior SDE高级软件开发工程师（小组领导。影响着3-12名工程师，或者是他们的行政领导；或者是他们的技术带头人）---Principal SDE首席软件开发工程师（团队领导。影响着10人以上的大团队，成为影响团队成败的关键人物）。书中还给出了有中国特色的好工程师的要素。
三， 通读完整本书之后，要成为一个善于交流，说到做到，接受团队赋予的角色，全力投入团队，融入团队的软件工程师。我认为，一个优秀的软件工程师，不管代码写的好与坏，首先要是一个善于交流，懂的合作的人，善于同团队交流，才有利于共同解决问题，才有利于代码复审等后期工作的展开，我相信，当软件公司在招聘人才时，首先会注重他的交流与表达，能否融入这个团队，其次才是写代码的能力。我希望自己在以后的学习过程中，要多与人交流，不能是自己独自一人闭门造车。
四， 第四个感悟就是规范化，读完这本书后，看了看自己大一一年写过的作业，如果不是自己单独给每个VC文件命名，有很多代码自己看完了都不知道这个的功能到底是什么，需要在重新运行一遍。在构建之法中，强调了团队规范的写代码的规定，比如4个空格要优于TAB键，其次在命名变量的时候要选取合适的单词作为变量名，截取我写的代码的片段，自己在没有阅读之前真的是太太太太太不规范了，太太太太太太太随意了
void Student::setStudent()
{
cin >> xuehao;
cin >> nianling;
cin >> name;
cout << "建立信息函数被调用" << endl;
}
学号，年龄等信息直接用拼音表示了出来，在写代码时虽然简单明了，但是现在再反过来看时，真的有些看不懂，不利于后期的改进和他人的阅读。自己第二个的缺点就是，没有注释！没有注释！没有注释！在作业中很多Class类是干什么的现在在看已经忘了，再加上自己代码写得很不规范，导致了我写的程序，连我自己都不明白这段程序是执行什么的，是完成什么功能的。
以上是我的部分感悟，构建之法这本书真的很好！正如前言所说，这本书就应该每个软件工程专业的人人手一本，这本书给我的感觉就是适合一直去读反复地去读，每个不同的阶段去读都会有新的感受。在小学期以后我回去读第二遍，第三遍，获益匪浅的好书!
《构建之法》读后感
写《构建之法》读后感的想法，其来已久，一直未能完成。拖延症爆发的原因大概有二，一是感觉吸收的不够丰富而无法反刍，二是选择不好读后感切入的角度。《构建之法》2014年出的第一版，买到书时已是开学季，想要调整... 查看详情
构建之法六章读后感
在本周我主要学习了构建之法的第五章和第六章，第五章主要讲述团队和流程，第六章主要讲述敏捷流程；软件团队的模式有：主治医师模式、明星模式、社区模式、业余剧团模式、秘密团队、特工团队、交响乐团模式、爵士乐... 查看详情
构建之法第十一章读后感
本周进行了构建之法的第十一章软件设计与实现的学习；第十一章主要讲了典型的开发流程，常见的分析和设计方法：ERD，DFD，UML，开发阶段的一些管理方法：每日构建，小强地狱，构建大师；分析和设计方法包括以文字为主的... 查看详情
读后感
《构建之法》读后感 《构建之法》是一本好书，当我翻开构建之法的第一页时，我就感觉我能从书中得到许多关于编程的方法和相关知识。 当我读到构建之法里的 “敏捷宣言表明的是... 查看详情
构建之法一二章读后感
这几天首先学习了构建之法的第一章和第二章。通过第一章的学习，我了解了计算机科学的领域、软件工程与计算机科学的关系、软件的特性以及软件工程的定义和组成部分；我们都知道，软件=程序+软件工程，而它的拓展是软... 查看详情
构建之法读后感part5
本周读到了构建之法的第五章，本章主要讲了几种软件团队的模式、软件开发流程。 邹欣老师的这本书，写得形象生动，第五章用体育运动等团队例子引出软件开发团队的形式。软件团队形式多样，适用于不同的人员与... 查看详情
构建之法读后感part4
本周读完了构建之法的第四章，本章内容主要是讲“两人合作”，有一句话众所周知“三个臭皮匠赛过诸葛亮”，无论是从事什么活动或者工作，合作的力量总是1+1>2软件开发的过程是复杂的，显然的一个人的智慧是不够的，... 查看详情
构建之法读后感part7
这个星期我看到了构建之法的第七章，第七章介绍了微软推荐的软件开发方法MSF。MSF的最大特性是商业化,并一直体现在项目的实施过程中。所谓商业化意味着客户的商业利益。客户投入多少，得到多少回报，客户要用到哪些最... 查看详情
读构建之法之感
读构建之法之感，为什么迟迟没有发构建之法这本书的观后感，是因为想要细细的看，为什么老师这么要求我们这么做，为什么要刻意的去发微博，原因都在构建之法的这本书中。构建之法这本书和其它的软件工程的书不同，构... 查看详情
构建之法读后感
构建之法的第八章主要是讲述了需求分析开发团队是主要为用户着想，在开发项目之前进行用户分析；讲述软件需求的4个步骤，（1）获取和引导需求（2）分析和定义需求（3）验证需求（4）在软件产品的生命周期中管理需求。... 查看详情
《构建之法》读后感
《构建之法》读后感 通过对本书的阅读首先让我了解了软件的组成：软件=软件工程+程序，对软件工程的意义有了更深入的理解。软件工程是在为了解决软件危机的背景下提出的，它使软件从需求分析到代码设计再到软... 查看详情
《构建之法》读后感02
通过阅读这一章的构建之法，让我感受最深的一个道理就是一个真正的软件是由多人完成的。虽然个人能力非常重要，但是团队之间的配合却是更为重要。而我们现在最缺少的就是这种团队之间的沟通交流。因为我们从... 查看详情
构建之法读后感
通过几天的阅读，初步对《构建之法》这本书有了初步的了解。最深的一点感受是这本书将开发过程中遇到的现实问题描绘的很好，很有幽默感。但是对一些专业术语不是很明白。比如开始都不知道最基本的瀑布模... 查看详情
《构建之法》读后感
这学期的软件测试课程多加了《构建之法》这本书，这学期利用自己的课余时间学了这本书，感觉受益匪浅。对于这本书可以简单地有两个词语来概括：“专业”、“接地气”。这本书的开头就是给我解释什么事软件、什么是软... 查看详情
构建之法读后感
第六章、敏捷流程1.Scrum方法论是敏捷过程的一种，敏捷过程的精髓在于快速交付。 1)第一步：找出完成产品需要做的事情-ProductBacklog。Backlog意为待解决的工作。 2)第二步：决定当前的冲刺需求决定的事... 查看详情
构建之法读后感part1
碰到《构建之法》，实属偶然。在进入大二的第二个学期正式选了软件工程方向，软件工程牵涉的范围很广, 同时也是一般院校的同学反映比较空洞乏味的课程。但是软件工程的技术对于投身IT产业的学生来说是非常重要的。... 查看详情
构建之法读后感
这学期的软件测试课程多加了《构建之法》这本书，这学期利用自己的课余时间学了这本书，感觉受益匪浅。对于这本书可以简单地有两个词语来概括：“专业”、“接地气”。这本书的开头就是给我解释什么事软件、什么是软... 查看详情
《构建之法》读后感5
软件工程涉及的范围很广，对于即将投身IT业的学生而言，软件工程的内容又非常重要。读构建之法，尽管本书介绍了不少IT业正在使用的理论和技术，但是，这本书的主要思想并不是介绍所有的新思想和新技术，而是从这些新... 查看详情