写在前面：
| 今天心情不错 抽了个时间将这本书剩下的内容阅读完毕了 确实收获很大 虽然我只是看懂了其中的理论 但感觉对于软件工程这个课程的理解 软件工程的流程的理解都有了很大的进步 起码以前的我并不知道该如何做一个真正的软件 通读完整本书后 对于软件工程有了一个大致的流程了解 希望下学期的学习中可以将学到的知识进行实践吧。 |
正文：
1.软件设计与实现
这一章主要讲述了如何进行分析和设计一个软件。分析和设计的方法有很多种，如图形建模：通过建立思维导图、实体关系图等描述各种角色之间的关系，进而分析出需求和功能。但方法有很多，在计算机 的发展过程中，涌现出了各种各样的方法，如形式化的方法，文学化编程等等。这些方法各有优缺点，没有一项是真正完美的。那么在我们分析完了并且写好了设计文档后，我们如何将这些需求实现呢？书上列出了一个程序员在拿到设计文档后的开发流程，通过这样的开发流程就可以使得开发过程更加规范化。在开发阶段，每天都会发生各种情况。比如有的程序员闭门造车，有的程序员不重视每日构建，同时在修复BUG的时候也会出现一些特别的情况：宽严皆误，即不论对于嵌入代码的要求是宽还是严，都是错误的。应该将这二者结合起来。最后还有可能会出现Bug Hell，即bug地狱，开发人员只着重于功能的开发，不重视BUG，使得BUG变得多到只能一个团队的人一起去修BUG的情况。同时在开发过程中的源码管理也有一定要求，对于源码，我们不能只保留最新的，要把从开始到最后发布的代码都保留下来，以便新入职的人员进行学习，同时也有利于BUG的修复以及日后的查看和修改。最后，代码完成了。这一过程也就正式结束了。
2.用户体验
上一章讲到，代码开发完成了。但软件的开发并没有结束。我们要通过用户的体验反馈来将我们的软件进行更进一步的优化，以便更好的满足用户和客户的需求。我们要考虑到各种情况，例如用户的第一印象，不要让用户犯一些简单的错误，这些都需要我们进行更好的设计。设计用户体验的办法有很多，比如快速原型调研，即用纸张模型，重现现在的软件状态，交给用户去评判。或者A/B测试，直接让现有用户测试新功能，看看用户是否满意。那么怎么才算是真正的好用户体验呢？书上提出了一些基本的原则，如尽快提供可感触的反馈，要符合用户的现实惯例，用户必须具有控制权等等。这些都是评判的一些依据。同时针对不同设备也有不同的需求，要根据实际情况进行实际考查。
3.软件测试
软件测试，一个让人听了既兴奋又难过的词汇。所有的软件发布之前必然要经过测试，不通过测试的肯定要打回。那么作者是如何对市面上那么多种软件测试进行分类的呢？作者通过各种角度进行了分类，如按测试方法的设计进行分类，有黑箱和白象测试；按测试目的进行分类，有功能测试，非功能测试；按测试的时机分类，如Smoke Test。这都是测试方法的设计，那么具体有哪些测试方法呢？作者介绍了包括单元测试，构建验证测试，验收测试等在内的十二种测试方法，具体不再展开。有了理论后，便是实战中的测试，要将理论应用于实战中，作者针对一些问题提出了自己的观点。并对一些错误的行为进行了纠正。之后，便是测试工具的真正使用了，这里因为我自己没有项目，没有办法实地展开，姑且跳过。
4.质量保障
软件完工后，通过测试后，还有很多要考虑的事情。质量的保障就是其中之一，做软件的最重要的是程序的健壮性。一个软件如果不够健壮，不时崩溃，这样的软件是无法发行的。那么首先从概念出发，软件的质量包括哪些呢？作者提出了一个公式，软件质量=程序质量+软件工程质量，分开来讲，程序的质量，很简单。程序能否稳定运行，是否算法足够迅捷。软件工程的质量就要包括更多方面，如软件开发过程的可见性，软件开发过程的风险控制等等。如何衡量软件工程的质量呢？可以使用一套名叫CMMI的体系，CMMI可以将软件工程细分五个等级，通过这个分级就可以明确的看到软件工程的质量。在知道了什么是软件质量后，就要来学习如何保障质量。首先是测试，测试这个角色应该独立出来吗？作者提出了自己的观点：应该。并且根据实际情况提出了面对测试角色的几个问题，例如盲目信任所谓专业人士，没有明确分工等等。这些都是测试角色需要解决的问题。
5.稳定和发布阶段
最终，代码完成了。最后便是稳定和发布阶段。我们可以通过会诊小组，通过会诊来分析软件中的一些BUG，并将其分类，细分为各种类别，将其中优先级最高的进行修复。就可以发布Alpha/Beta 版本了。在Alpha/Beta 阶段时，用户会提出很多的反馈，通过这些反馈，将其需求仍然按照优先级次序排列，优先实现优先级高的需求。同时我们也要确保在开发过程中，旧的可见可修复BUG都要修复好，以防以后出现新的BUG形成连锁反应，使得软件发布的周期再度延长。实在不行，直接砍掉一些功能。这也是可以接受的。在经过一系列的稳定操作后，软件正式发布了。发布后也不是说没事了，要开展所谓事后诸葛亮会议，将我们在整个项目开发中出现的问题，以及进度需求等等进行一个汇总，以便对以后进行更好的帮助。
6.IT 行业的创新
创新，听着就很美妙的词汇。但创新到底来源于何处？创新真的能被大众所接受吗？这些都是作者关于创新的一些思考。我在这里就我自己谈一下自己的看法。创新，毫无疑问是各种知识的积累，创新的出现不仅需要知识的积累，也需要各种机缘巧合，但这都是量变引起质变，只有量变到了一定的程度，才会出现所谓的突破口，达到真正的质变。但不仅如此，即便提出了创新，尤其是颠覆性的创新，无疑会改变世界的格局，如手机的普及，WWW的出现等等，这些创新改变了世界。但这些创新提出的时候一定会受到来自各方的阻扰。人们总是不习惯改变，更何况这个改变会让自己丢掉自己一直以来坚守的，自己一直以来信仰的东西。在大学里，老师如果想对课程内容进行修改，向领导提交，有的领导就会驳回，理由是，没有这样的先例。没有这样的先例便不可了吗？所以说，创新的实现是十分复杂且困难的。且不论想出来的难度，就算真的想了出来，想要推而广之又是更加辛苦的工作。因此，我们自己要踏踏实实的积累自己的量变，积极的思考，才能真正的触摸到创新的界限。
7.人，绩效和职业道德
这里，作者提到了人，绩效等等。但这一块内容看的迷迷糊糊，只能说理解了一二。暂且不做总结了。
总结：这本书，作者的文笔十分幽默，且作者提出一个概念时，必然伴随着一个生动的例子来帮助你理解。这是我所欣赏的。这种知识类的书籍，很难做到这种一下子看七八十页的感觉。《构建之法》做到了。他让我真切的明白了什么叫软件工程，对于软件开发的各个流程有了一定的了解，同时也对下学期的课程多了几分期待，期待成长后的自己。