阅读《构造之法》2

<构造之法>和其他接触过的教材有所区别,不像别的教材那样呆板,无趣,让人读着想睡觉,感觉像是在听笔者在讲述他的所见所闻,或者像在读一本小说,让人可以一直跟着读下去,而且能学到一些东西. 在第一章中,有许多生动有趣的例子(事实整本书都有许多),让我能很有兴趣的慢慢读下来,也比较明白了软件工程什么,它所包含的方面以及意义,软件工程与许多的学科都有联系,这些联系或多或少,也说明了软件工程不单单只是涉及到一方面.软件工程的目标也比较明确,看这些可以解决自己对这一专业的迷惑.第二章则深入一些的讲到了对于

<构造之法>简明.易懂,第4章讲到了两人结对合作来完成代码的编写,这也是当今软件工程师经常接触的事情,一个人完成项目是好,但未必不会出现错误,而且自己检查起代码来也难免出现疏忽的地方,而结对则有多人进行代码的复审,出现错误的几率就会大大减低,而且结对可以优势互补,尽量发挥出各人的长处. 第4章一开始就讲的是代码的规范问题,其实这个很重要,对于一个比较大量的代码,如无意义的命名方式,可能编写者自己都会一时想不起它有何作用,更不用说别人了,所以代码规范对于一个团队来说,可以让团队里的人更清晰明了的

几个星期前,我阅读过一篇文章,一位老师教导自己的学生要积极地去阅读文学文献,其中,我很欣赏他的一句话:“Just think of liturature as if you're reading a long text-message”.引申到这里,对比后才发现自己在现实生活中真的很少在课后花时间来细看自己的专业书籍,说来惭愧,这种情况出现的频率最多的就是在学期末备战考试了.因为这次的作业,我似乎告诉自己这是一个非常“恰当”的理由去让自己提前去完成未完的“任务”.阅读一本书,就要认真,要对得起自

通过阅读<构造之法>第四章,我知道了程序员写的代码要规范,代码虽然是给机器看的,让机器来运行,但是更要给人看,代码是人写的,都会有各种各样的缺陷,必然要去修复.改进,若代码不规范,带来的影响是比较严重的,会让人感到烦躁,看不下去了.或者因为看懂代码的缺陷在哪里而花费了大量的时间.在代码上要4个空格来缩进.为了调试起来方便,需要断行,每个“{”和“}”都独占一行,一行代码不要定义多个变量,由多个单词组成的变量名需要有大小写,其中每个单词的开头第一个字母大写,不要多余的注释. 代码复审是有必要的,

几个星期前,我阅读过一篇文章,一位老师教导自己的学生要积极地去阅读文学文献,其中,我很欣赏他的一句话:“Just think of liturature as if you're reading a long text-message”.引申到这里,对比后才发现自己在现实生活中真的很少在课后花时间来细看自己的专业书籍,说来惭愧,这种情况出现的频率最多的就是在学期末备战考试了.因为这次的作业,我似乎告诉自己这是一个非常“恰当”的理由去让自己提前去完成未完的“任务”.阅读一本书,就要认真,要对得起自

    第一次阅读构建之法,把以前很多门课的知识点联系到了一起.      软件=程序+软件工程.我认为这是对软件的一种及其精炼的解释.程序即是指一行行代码,软件工程则包含了各种软件开发活动,包括构建管理.源代码管理.软件设计.软件测试.项目管理等等,是把系统的.有序的.可量化的方法应用到软件的开发.运营和维护上的过程.      从一个简单的程序,扩展到一个满足各种功能的应用软件,再扩展到一个能保证服务质量的软件服务.源程序是建立在数据结构上的一些算法.构建不仅仅是CC和link命令,一个复杂

现代软件工程方法之所以超出传统方法,主要是因为它针对的是具体对象,即面向的是具体存在的问题和弊端,这一点,完全克服了传统软件工程方法的缺点和不足.现代软件工程方法包含五部分,分别是分析.设计.编码.测试.维护.这几部分虽与传统工程方法大同小异,但细比较便可发现现代工程方法的优点.在分析部分,传统工程方法主要是笼统地分析,没有具体的面向对象,而现代工程方法则是分析现实事件的具体问题,因此,具体问题的性质可以更好地反映事件的性质.在设计部分,面向对象主要是系统中的具体时间.构造之法的主要作用--提高

题意: 生成 1~n 集合的子集, 先按元素从小到大再按字典序排列输出 分析: 所谓构造增量法, 就是每次都输出当前数组的元素, 然后再给当前数组最大元素一个增量, 看是否仍然在集合内, 如果在就把他继续放进数组, 输出. 这种方法不需要显式确认递归边界, 如果无法添加元素, 自然就不会再递归了. 数据结构我选用了string , 因为字典序比较容易排序出来. #include <bits/stdc++.h> using namespace std; string ans[1 <<

 构造之法 第一章里面的软件工程的知识领域的1.Software Requirements,软件工程的需求分析,概括了我不懂的东西. 第二章里面的个人开发流程,职业工程师和大学生的软件开发耗时表对我启发很大,不同方面的时间分配反映出来了各自质量要求的不同,在此我有一个问题:只有时间沉淀出来的工程师才是一个好的软件工程师吗?岂不是我们大学生一定要等到40多岁才能熬出头了? 第三章里面的个人能力的衡量和发展,我觉得里面举的足球队例子不是很好地说明了个人能力的衡量度,在我看来工程师开发团队里面的开发维