构建之法后三章读后感

Posted 2020-09-17 online杜

    开始读这本书，最大的感受的感受就是软件工程原来是可以这么学的，以前学习软件工程的课程的时候，总是感觉这门课程及其枯燥无味，总是在说太多的理论，很少 会涉及到实践，甚至根本就是没有实践这个环节，所以学习很无聊，但是读到这本书，真的是全新的感受，首先，不仅仅只是在说理论了，加入了很多实 践的东西，而且还可以在网上可以与其他人进行交流学习心得。

       整本书从实际软件开发的各个阶段出发，详细地分析了软件工程的各个环节，如：需求分析、设计实现、用户体验、软件测试已经最后的发布等等。

   首 先，说说代码风格，一个良好的代码风格规范是一个软件开发人员最起码的要求，即使程序写得是多么地出色，具有广阔的市场应用前景，但是如果背后是混乱不堪 的代码，那么就会对这个软件日后产生不少的负面的影响，特别是在后期的维护以及版本的迭代上，不规范的代码对于日后的维护人员来说，简直就是噩梦，以至于 最后实在是没办法了，只好是全部推倒重写，当然这个最坏的打算了，所以好的代码规范是多么地重要，特别是在日后开发具有商业价值的项目时，或者是在一个软件项目的团队里工作，代码规范相当重要。

   敏捷（Agile）开发，也是一个很早就提出来的技术解决方案，敏捷是一系列的价值观和方法论的集合，前人通过 不断地实践，总结出来的开发方法及开发过程，对我们现在的开发有很强的指导意义，敏捷开发的原则很多，其中印象最深的就是“经常发布可用的软件，发布间隔 可以从几周到几个月，能短则短”，以及“可用的软件是衡量项目进展的主要指标”，我的理解是敏捷开发强调的是“小而美”，定期地完成一个小版本的软件项 目，比只是最终发布产品要好的多，这样也有利于产品的迭代，敏捷中的Scrum方法论，看起来简直就是无与伦比：要做什么->当前要解决什么 ->冲刺->得到一个增量版本。分阶段地不断递进地解决问题，但是敏捷也有很多的弊端，敏捷宣言不是圣旨，不必完全尊从，就像是Scrum， 实际执行的时候也不是看上去那么美好，在一个复杂的项目中，往往不能带给团队更多的惊喜，所以，敏捷慎用。

             最后来说说软件测试，不仅仅是这本书中，几乎所有的介绍测试相关的书籍，都对测试讲得很多很多，说到测试，大家最熟悉的就是黑盒、白盒测试等，要写好一个不错的测试，首先要有一个好的测试方法，如：Unit Test、Function Test、Structure Test、System Test等等，测试方法多种多样，关键是怎样找出合适的测试方法最好地完成测试，怎样写一个Test Case?这个好像很麻烦，你必须首先知道并熟悉这个需求，要写出一个完整的测试过程，要考虑好测试的边界值的选取，极端情况下程序的健壮性，所以写好一个测试不简单。

学好软件工程也是不简单的。