最后一篇阅读笔记，阅读内容是第十一章到最后。
我们写软件就是要解决用户的需求，在设计上理所当然要按照用户的想法去规划方向。上学期我们学习过UML，这就是设计模型的一种方法，通过图示让用户明白我们这个是什么结构，关联如何，怎么使用。此外还有其他的方法，比如说明书（文档）。但我们要讨论的是更加细节的东西，在接手一个项目的时候，你要考虑到你在一个团队中，你所写的东西不仅要让用户明白，还要让其他开发者明白，在面向其他开发人员的时候，大家都是这个行业的，未必像用户那样只能用“傻瓜式”说明，然而你需要让别人清楚你做到哪里，进度是多少，因此需要按时给出进度报告，同时要把问题说明出来，同行是有能力帮你解决问题的。
我们平时在完成老师布置的作业的时候，尚且需要进行测试，输入各种样例，对比结果之类的。当开发软件的时候，就需要用户进行使用来收集反馈信息，藉此进行更新。那么我们在设计软件的时候理所当然地要考虑用户体验问题，避免做的太糙而导致最终终止交易。书上给出了详细的设计步骤，简单概括就是：理解用户需求；设计相应解决行为；给出界面。任何大型软件刚开始都比较简陋，毕竟存在技术受限等问题，更多的是他们一开始只想解决这个问题，之后在这个功能的基础上又慢慢添加了其他功能，最后越做越大，在积累过程中这些新功能的想法并不是凭空产生，而是做了市场调研，根据用户反馈而推断出的结果。这也是设计者所必须具备的思想。
刚才提到的测试是对产品的测试，而软件由一个个模块组成，参与编程者在设计模块的时候同样需要测试，这里测试可不是随便输入两个样例就可以了，测试者需要从各个角度去考虑，而开发人员编写代码之后，即使是测试也会下意识按照自己的功能来，存在思维盲区，或许这就是将测试与开发交给两波人去做的原因吧。即使是我们这些圈外人，能想到的测试也是效能测试，也就是看看软件是否高效。而测试人员除了那个之外，还要考虑压力测试，场景测试等等，并且要撰写相应的文档，最后在交出软件的时候，也要根据用户的反馈进行查缺补漏。
我们在买东西的时候都要思考这个东西质量好不好，那么软件的质量该如何界定，一般的想法都是“好不好用”，但读过书后我才明白，这只是其中一点。功能的好坏反应的是“程序的质量”，而从一个工程的角度上来讲，你需要衡量的还有时间因素，即开发时间。比如给你10年开发一个软件，另外一个团队1年就开发出来了，哪怕你功能再强，再优秀，也鲜少有用户会选择跟你合作。而时间因素又是跟程序质量有着密不可分的关系，如果你的程序质量不高，Bug就多，改Bug是很费时间的，一来二去你用的时间就多，时间质量就会下降，投入的成本也会增多。所以开发软件时，各项因素是一环扣一环的，切忌马虎大意。而软件发布之后不代表什么事情都没有了，你需要做一些“善后”工作，比如总结经验等等，这都是理所当然的事情。
本书最后提及了IT行业的创新与职业道德之类的，我自诩现在还考虑不了那么远的事情，因为现在的我技术还是硬伤。