构建之法的读后感
Posted 李嘉来
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了构建之法的读后感相关的知识,希望对你有一定的参考价值。
构建之法的读后感
七月份读完了构建之法这本书,粗读,基本了解了软件工程这个专业的工作,就业,和前景。目前有如下体会(构建之法这本书正如前言所介绍,适合软件工程的任何阶段去读,我现在只阅读了一遍,还会继续地读下去):
一, 原来,软件工程并不是像我再选专业之前认为的那样,只是一群人在一起敲代码。软件工程的定义是把系统的,有序的,可量化的方法应用到软件的开发,运营和维护上的过程。(构建之法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类是干什么的现在在看已经忘了,再加上自己代码写得很不规范,导致了我写的程序,连我自己都不明白这段程序是执行什么的,是完成什么功能的。
以上是我的部分感悟,构建之法这本书真的很好!正如前言所说,这本书就应该每个软件工程专业的人人手一本,这本书给我的感觉就是适合一直去读反复地去读,每个不同的阶段去读都会有新的感受。在小学期以后我回去读第二遍,第三遍,获益匪浅的好书!
以上是关于构建之法的读后感的主要内容,如果未能解决你的问题,请参考以下文章