《构建之法——现代软件工程》读书笔记(一)

我们两清 提交于 2020-01-19 16:19:55

经过了几天的阅读,看完了前六章。想着对这些部分做一个总结。

这本书其实际来说,就是在讲软件工程的流程和各个部分的介绍。不同于其他的书,只有文字。这本书有文字,有例子,也有代码。解释的很清楚。并且作者的语言十分诙谐幽默,读起来确实很快,不知不觉就看了二三十页。内容也不是如课本那样十分枯燥的内容。并且各个小节也讲的十分清楚。

作者在第一章提出了一个综述,即什么是软件,什么是软件工程,对于这部分作者不仅提到了基本的定义,还就提出这些定义的理由进行了解释。我们大家都知道, 程序=算法+数据结构,但是包括我自己在内,一直有一个疑问,我学了数据结构,有什么用呢?我在C语言中实现了二叉树的各个算法,但是java中又不使用指针,那么我学习二叉树又有什么用呢?作者通过一个例子来详细的解释了其用处。软件=程序+软件工程。一个软件的实现必然会用到算法和数据结构等设计,但软件是给人用的,人们必然有各种要求,软件公司又要赚钱,那么又是怎么个商业模式呢?这些都是软件工程来考虑的问题范畴。软件工程是什么呢?其实软件工程就是把各种实际的方法用到软件的开发运营和维护上。注重实践。这也是作者提出的learn by doing(做中学)的一个合理解释。软件工程是注重实践的,比起创新,稳定来的更为重要。基于软件的各种特殊性,人们总结了一系列对于软件的方法,这些方法实用起来就是所谓的软件工程了。

在第一章介绍了软件工程概念的基础上,第二章又开始介绍一个人开发软件的流程和技术。即PSP(Personal Software Process) 在问题的伊始,为了保证各个软件中各个模块的稳定性和质量,需要进行单元测试,在这个章节中,作者首先介绍了用VSTS(Visual Studio Team System 由微软开发的一套生命周期管理工具)进行单元测试。这部分由于我自己没有开发的经验,看的迷迷糊糊的。也就不再班门弄斧了。在介绍完后,作者提出了对于单元测试好坏的判定标准。毕竟单元测试也分做的好的和做的不行的。并针对这些提出了一系列的要求。单元测试后,作者又提出了一种回归测试。这种测试是基于单元测试的。所谓的回归(Regress)即倒退,退化的意思。在项目中,如果一个模块以前是正常的,新的构建中却出了问题,就说这个模块发生了一个退步,我们要做的就是修复这个退步,并且继续开发下去。这也就是所谓的回归测试。在这之后,作者介绍了效能分析工具。这种工具可以用来分析算法的复杂度,并帮助人们改善情况。基于以上的单元测试和效能分析工具这两种工具,作者提出了PSP,个人开发的具体流程。并详细介绍了PSP的特点。在这之后,作者提出,每个人要开始管理自己的源代码,并且对软件工程课程的开设提出了自己的一些要求。

第三章, 笔锋一转,提出了评价一个软件工程师的主要方法。个人能力的提高,作者认为有五种方式:1.积累软件开发的相关知识,提升技术技能,比如对于编程语言的掌握,等等。2.积累问题领域的知识和经验。3.对通用的软件设计思想和软件工程思想的理解。4.提升职业技能 ,包括自我管理的能力,表达和交流的能力,与人合作的能力等等。5.实际成果,即实际的项目等。那么如何衡量软件开发的工作量和质量?PSP认为有四个因素:a 项目/任务有多大,b 花了多少时间 c 质量如何 d 是否按时交付。除此之外,在团队中,也有对于个人的期待。相对于PSP,有TSP(Team Software Process),TSP对团队成员也有着很多要求,如交流,说到做到,全力投入等等。在结束了这部分的讲解后,作者指出了软件工程师的一些思维误区:分析麻痹、不分主次,想解决所有依赖问题、过早优化、过早泛化。最后,作者提出了对于软件工程师的职业发展方向。对于我个人的发展有了很大进步。最后的最后,作者通过技能的反面这一概念讲了如何提升自己的技能。

第四章,两人合作。一个项目,大部分情况下都是由很多人一起写的。那么在这种情况下,就对代码的规范,有了一定要求。作者提出了对于代码的规范的两个分类——代码风格规范和代码设计规范。这部分内容很明显与我自己的开发也息息相关。我尽量做到在以后的编程中按照这些规范来写程序,这样才能让程序被别人看懂,进而改进。同时也方便自己日后看懂。在代码的最后,要进行代码复审。代码复审就是找出代码的错误,并且优化代码的算法。在这样的情况下,作者提出了结对编程的概念:结对编程,即两人一起在一起关在一个小黑屋里进行同时同进度的编程,随时进行代码复审。这种方法有好处但也有坏处。最后作者提出了两人合作的不同阶段和技巧。指出在合作中要学会正确的交流,不仅能把自己的想法传递给对方,还要说的好听。

第五章,团队。在两人合作的基础上,就发展到了一个团队。软件团队有着各种各样的模式。作者从一窝蜂模式(Chaos Team) Chaos其实就是英语里混乱的意思,其最起初的混乱模式,到逐渐形成有分工,分工明确,每个人有任务的功能团队模式(Feature Team)在这样的团队里,每个人都有着各自固定的职能,这样的模式也是被大多数现代公司所采用的一种模式。同时也介绍了一种走偏的模式——官僚模式,这种模式中各个老板都为了利益而争夺,十分不平衡。一个好的团队模式对于开发的好处是难以言表的。在好的团队模式中,设计效率和质量都会有着极大的提升。在开发中,也有一些开发流程。从写了再改模式到RUP(Rational Unified Process 统一流程),这一方法集大成的吸收了瀑布模型的特点,对于复杂的软件项目有着很好的解决方案。最后提出了一种最接近迭代式开发流程的渐进交付的流程,即开发,发布,听取意见,改进。不断重复这个流程。

第六章,提出了敏捷流程的概念。敏捷流程是一堆方法论的总结,是一种软件开发的思想。作者从理论和实际分别出发,分析了敏捷流程的问题和解法,最后对其做了一定的完善。在最后的敏捷总结中,作者对敏捷流程的本质进行了一定程度的分析。并通过一系列的问答指出,敏捷也有其使用范围。详细分析了敏捷流程的足与不足。对未来也进行了展望。

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!