Book Review 《构建之法》
- -首先浏览了一遍《构建之法》这本书的前言,其中通过客观的描述性介绍了学生与学习、老师与教学、以及学习的环境、方法等等。但是对于书中前言包括正文都频繁出现的一个词语 “文档” 深表疑问.何为文档,是指带代码?还是另有其他含义。
- -接着看下去,第一章用前言的风格,阐述了软件含义,软件工程与计算机科学,Bug.对于软件的阶段性,个人理解来说就是软件是要一步步来提升完善.由开始的感兴趣到动手出成品再到完善维护这都是一步一步来进行的.软件工程是为了某个特定的目的而专门建立的一个项目工程,所谓工程就有一定的层次性这一点也是跟程序开发是类似的具有阶段性.书中也是提及计算机科学和软件工程的侧重点.前者就像是JAVA 中的主类,而后者是子类。 软件工程 的进展会为 计算机科学 提供跟多的“资源”,帮助科学家做跟多的实验探索。而计算机科学得进展会提高软件工程的正确性.就像是父类对子类的一个完善,提升.子类对父类的一个反馈。最后是Bug这个词,以前的理解就是系统出现的漏洞,不完善的地方,指代不好的东西、地方.而书中给出了另一种说法"Bug 就是软件的行为和用户的期望值不一样.",没有褒贬的意味。这个倒是有点出乎意料,但也是很生动的体现出程序的针对性.不合适就是不好 !
- -第二章的一开始就出现了”单元测试“.呵呵,这个正是上次作业老师给的一个建议。在看了第二章之后觉得对单元测试有了一个模糊的理解.没有十分的清晰的概念,感觉就是增加模块去捕捉软件运行出现的错误并给予提示。这里希望老师可以指点下”单元测试“的具体意思- 。-
- -至于第三章关于软件工程师的成长:在学习阶段首先就是要对自己有一个全面提升,无论在专业技能,还是经验、思想等。再在实践中根据自己的情况选择在哪个方面追求“专和精”,在那几个方面达到“知道就好“的水平.来提高自己的核心竞争力。
- -第四章两人合作,一个团队中需要有统一的代码风格。在结对编程的过程中要时刻进行复审.换句话说就是要自我复审、同伴复审、团队复审。更正并且记录下错误,进行一个自我的提升.无论结对还是团队都是有一定的阶段性的,并且都是可以提高程序总体的质量的。但是这都是有前提:“必须有一个团队、结对”,那么在进行结对也好团队合作也罢前,岂不是要花费很多时间去找合适同伴,相互磨合.不然中途如果发生激烈的冲突导致解体的话就会对整个项目造成致命伤害了?
- -在两人合作之后就是团队合作,在第五章中强调了团队合作的各种模式:社区、业余剧团、秘密团队、特工团队、交响乐团队等等很多种模式,适合各种不同类型的项目,具备自己的优点短处。在书中强调出团队之间队员的关系与分工,还有就是项目的流程。一个团队要想成功合作,那就离不开模式指引,而一个项目需要模型来引路。那么一个团队如何去确定一个合适的团队模式呢?一个项目怎么知道那种流程是最好的呢?
做真正的自己,活出别人没有的快乐。