首页 > 代码库 > 构建之法后三章读后感
构建之法后三章读后感
开始读这本书,最大的感受的感受就是软件工程原来是可以这么学的,以前学习软件工程的课程的时候,总是感觉这门课程及其枯燥无味,总是在说太多的理论,很少 会涉及到实践,甚至根本就是没有实践这个环节,所以学习很无聊,但是读到这本书,真的是全新的感受,首先,不仅仅只是在说理论了,加入了很多实 践的东西,而且还可以在网上可以与其他人进行交流学习心得。
整本书从实际软件开发的各个阶段出发,详细地分析了软件工程的各个环节,如:需求分析、设计实现、用户体验、软件测试已经最后的发布等等。
首 先,说说代码风格,一个良好的代码风格规范是一个软件开发人员最起码的要求,即使程序写得是多么地出色,具有广阔的市场应用前景,但是如果背后是混乱不堪 的代码,那么就会对这个软件日后产生不少的负面的影响,特别是在后期的维护以及版本的迭代上,不规范的代码对于日后的维护人员来说,简直就是噩梦,以至于 最后实在是没办法了,只好是全部推倒重写,当然这个最坏的打算了,所以好的代码规范是多么地重要,特别是在日后开发具有商业价值的项目时,或者是在一个软件项目的团队里工作,代码规范相当重要。
敏捷(Agile)开发,也是一个很早就提出来的技术解决方案,敏捷是一系列的价值观和方法论的集合,前人通过 不断地实践,总结出来的开发方法及开发过程,对我们现在的开发有很强的指导意义,敏捷开发的原则很多,其中印象最深的就是“经常发布可用的软件,发布间隔 可以从几周到几个月,能短则短”,以及“可用的软件是衡量项目进展的主要指标”,我的理解是敏捷开发强调的是“小而美”,定期地完成一个小版本的软件项 目,比只是最终发布产品要好的多,这样也有利于产品的迭代,敏捷中的Scrum方法论,看起来简直就是无与伦比:要做什么->当前要解决什么 ->冲刺->得到一个增量版本。分阶段地不断递进地解决问题,但是敏捷也有很多的弊端,敏捷宣言不是圣旨,不必完全尊从,就像是Scrum, 实际执行的时候也不是看上去那么美好,在一个复杂的项目中,往往不能带给团队更多的惊喜,所以,敏捷慎用。
最后来说说软件测试,不仅仅是这本书中,几乎所有的介绍测试相关的书籍,都对测试讲得很多很多,说到测试,大家最熟悉的就是黑盒、白盒测试等,要写好一个不错的测试,首先要有一个好的测试方法,如:Unit Test、Function Test、Structure Test、System Test等等,测试方法多种多样,关键是怎样找出合适的测试方法最好地完成测试,怎样写一个Test Case?这个好像很麻烦,你必须首先知道并熟悉这个需求,要写出一个完整的测试过程,要考虑好测试的边界值的选取,极端情况下程序的健壮性,所以写好一个测试不简单。
学好软件工程也是不简单的。
构建之法后三章读后感