<构建之法>之一至二章

身在大学,却想起了在高中的生活和初中的生活,特别是初中的生活,为什么这么说呢!因为《构建之法》,看了其中的两章的内容,为什么想到了初中和高中的生活呢,因为在高中和初三的时候看的最多的就是课本,虽然有时会看不进去,但是同样会硬着头皮去看,因为要想考一个好的高中所以就认真的学习,看书。但是到了大学,可以说很少去看课本了,都开始看电子版的书了,当然看的电子版的书,就分好坏了,(其实书都分好坏,主要是看你怎么去看待它,在书中看到的是什么,是主人公的坚持不懈的努力,还是一些其他的东西!)而我就看了好几本的小说,科幻小说,玄幻小说,都市小说,可以说都看过,但是坚持看完的却是一只手能数出来,可见我对书的耐心真的不怎么样,但是没事的时候我也在想,我为什么能看完那“少有的几本书”,想我为什么能看完,耐心?好奇心?还是不知道自己干什么闲的了,想来想去我得到了一个最后一个结果就是闲的了。

而到了上了大学(大一)我就连看小说的心都没有了,觉得没什意思。而这样的结果导致我很无聊,很闲,除了上课认真听讲之外真的没有去想过去看什么书,但是到了大二,觉得自己对现在所学的专业还挺感兴趣的(虽然这个专业还是姐姐帮我选的),再到后来也就是到大二的时候我得到了一本书,刚开始得到这本书时,我就是硬着头皮在去看,曾经有几天我真的没想去看它,因为我在硬着头皮听书,因为我觉得听书会让我更舒服些,也许是因为老师的一句话,也许是不知道什么原因,我就每天硬着头皮去看,时间长了自己从进入看书的状态到结束看书,跑神的次数越来越少,并同时感觉读书还不错啊,至少自己不会那么闲,那么无聊了,老师说:“读书的心,需要慢慢呵护起来”,我想我现在应该处于呵护的初级状态吧!因为自己看书不知道是习惯还是怎么回事,就是一个一个字的去看,去读,而如果中途出现跑神的话就会重读(但是就是这样读过之后不久仍会忘)。曾看大到一句话大概意思就是说:读书的好坏不是你能记住多少,而是你能否在适当时候让它自然而然的浮现在自己的脑海里

《构建之法》之章一

看第一章首先看到的两个大字就是概括,没有理它,继续往下看,看到了”软件=程序+软件工程“今天看到这个等式多少有些理解,所谓的软件就好比是一间房子它需要有架构和一些装饰它才算是一间房子而软件也一样,一个大的软件就是一些小的程序组合起来的,而这些程序是怎么组合起来的,该怎么组合,怎么组合才能使这个软件(房子)更坚固,更不容易出现问题(bug),这时就需要软件工程(工程师)来完成了。

在往下看,看到了一句第一次看到它,我不懂什么意思,第二次看依然很朦胧,再次看它时觉得很经典很有道理的一句话:”程序=算法+数据结构“;而我从这句话看到了我的进步,因为我从不懂到理解,我就是在进步,说明我在进步,所以每当看到这句话我会很高兴,很喜欢这句话。

再之后看到的两句还就是:“软件=程序+软件工程,软件企业=软件+商业模式”从前者推到后者,增加了我对这两句话的理解。更明确,更深刻一些。

在之后看到的就是我认为本章最深刻最重要的内容------软件的开发的不同阶段,分成了:

1.玩具阶段。

2.业余爱好阶段。

3.探索阶段。

4.成熟的产业阶段。

而我个人认为暗含:

1.好奇阶段。

2.喜欢阶段。

3.毅力阶段。(重中之重)

4.成功阶段。

我理解的四个阶段,我认为毅力阶段是重中之重,是四个阶段的核心毅力阶段的成功与否是能否走向成功阶段的基础。虽然经历毅力阶段不一定能走进成功阶段,但是如果你不走完毅力阶段那你将永远无缘与成功阶段。

再然后让我记忆深刻的就是软件工程的目标了,什么是软件工程的目标,那就是足够好的软件,什么才是足够好的软件呢。个人理解为尽可能的满足于客户的需求,信奉顾客就是上帝.还有就是尽可能的,在此基础之上尽可能的消除软件的bug,从而提高软件的可靠性,可维护性。

《构建之法》之章二

第二章讲的是个人的技术和流程,记得上第一节课的时候老师就让我们在书的首页,写上,两个大字“流程”,刚开始真的不知道老师为什么让写这两个字。不知道是什么意思,跟这本书又有什么关系。不过依然写上了两个大字“流程”!

在第二章首先看到的是让我第一次上机课就很找不到头绪的,单元测试,不知道怎么去测试,不知道测试有什意思。为什么要测试,程序写好了运行一下能运行一下不就行了,为什么还要测试,还非让代码的作者去测试,真的麻烦,但是,看完之后觉得测试是很有必要的,个人理解为:单元测试结果的好坏,是检测一个程序的好坏的标准,是检测一个程序是否有隐藏的bug的标准。一个好的标准的单元测试能找到程序运行快慢的原因,从而进行程序的提高。

在这之后的回归测试看的就不懂了,还有就是什么抽样,和代码注入,真的很不懂,但是有一点看懂了,那就是代码的写法不一样那源代码中的一个函数的调用的次数就会不一样,从而导致调用的时间也就会不一样。在这里也理解到了效能测试的重要性。

在之后的个人开发流程就更让我感到很是不爽了,什么psp有什么用啊,而且每次都把psp都读成ppt,同样的第一次看时,不知道有什么用,干什么的,麻不麻烦啊!但是用过几次之后,回来再看时就觉得很有必要,psp就像是一个计划表一样,可以很清晰的看到一个团队的工作流程,还可以通过不同时间的不同的psp进行计较,进而看到团队的提高,一个团队的水平!

以上均属个人理解!

时间: 2024-10-09 22:31:49

<构建之法>之一至二章的相关文章

《构建之法》第四章---阅读总结

<构建之法>第四章---阅读总结 前言 看到这个章节的名字,我想起了之前老师叫我们看的<硅谷传奇>,原来老师是想让我们在学这一章节之前先了解两人合作的重要性.确实,软件工程既然能带上“工程”二字,那就说明它并不是一个人的事情,软件工程离不开团队合作,而团队合作的最简形态就是两人合作.由<硅谷传奇>可知,一个好的合作伙伴是多么重要,两人能有着共同的追求,又能包容对方的性格,各施其长后能力就不再是简单的1加1了. 分析与理解 本章节围绕“两人合作”的中心,主要讲解了编程规范

20179215 《构建之法》第三章

<构建之法>第三章 读书笔记 ?本章为软件工程师的成长,主要介绍了评价软件工程师水平的主要方法,技能的反面,TSP对个人的要求. 一.个人能力的衡量与发展 ?软件开发流程:软件开发流程包括团队的流程,也包括个人的流程 ?软件系统的绝大部分模块都是由个人开发或维护的.在软件工程的术语中,我们把这些单个的成员叫做Individ-ual Contributor(IC).IC在团队中的流程如下. 通过交流.实验.快速原型等方法,理解问题.需求或任务 提出多种解决办法并估计工作量 其中包括寻找以前的解决

读《构建之法》第四章 、第十七章

第四章    两人合作 通过对于<构建之法>第四章的阅读使我对代码规范 . 代码复审 . 以及结对编程有了更加深刻的认识,所谓代码规范可以分为两个部分,代码风格规范和代码设计规范,代码风格规范的原则是:简明 . 易读 . 无二义性,代码书写的形式,变量命名的方法,注释程序如何工作都有详细的介绍,令我受益颇多.代码设计规范不光是程序书写的格式问题,而且牵涉到咸亨需设计 . 模块之间的联系 . 设计模式等方方面面,函数的设计,语句的使用,错误的处理,这些都是我们在进行程序设计的时候需要注意的地方.

阅读《构建之法》第四章、第十七章收获

阅读<构建之法>第四章.第十七章 阅读这一章的时候,我意识到了很多以前写程序没有注意到的地方,以前写程序就只知道能运行就好,根本不管自己写的程序占多少内存,运行的时间,是否有优化的空间,写代码的时候也不注意规范,有时候设计的函数根本用不上,造成代码冗余.同时也认识到结对编程的重要性,没读这本书之前就觉得结对编程就是两个人一人负责一个模块,然后合在一起,调试调试.但实则不然,真正的结对编程应该像书中那样,一个是驾驶人,一个是领航人,两个人有规律的进行编程.期间,一人编程一人复审,极大地提高了效率

构建之法五、六章读后感

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

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

首先,文章对于程序.用户需求.工程等等概念用了阿超给儿子编写的一个出题程序来分别解释了个中的含义,尤其是程序和工程的区别,程序大概就是用很多语言或工具编写的一个简单能实现目标要求的一行行代码,而工程就是在这个程序的基础上不断满足用户的需求.修复程序的bug.提供后续维护等服务. 需求分析:梳理需求,逐步展开后续工作,如设计(软件架构).实现(写数据结构和算法),测试,发布软件 软件=程序+软件工程(软件企业=软件+商业模式) 软将工程的核心部分:构建管理.源代码管理.软件设计.软件测试.项目管理

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

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

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

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

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

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