第 15 章 软件工程和应用调试.pdfVIP

第 15 章　软件⼯程与应⽤调试 前⾯⼏章中讲过的Hello猫咪、打地⿏以及其他应⽤都是些⾮常⼩的软件项⽬， 不需 要⽤引⼊软件⼯程的概念。⼯程的概念借⽤⾃其他⾏业，意为设计 建造，教程中的 应⽤就像是⽤预制件拼装起来的房屋模型，⽽软件⼯程才是设计 建造真正⽤来居住 的房⼦。这个例⼦虽然稍显夸张，但⼀般来讲，某些极其复杂的建造过程，的确需要 ⼤量的前期构思、规划以及技术分析，这些过程都可以归结为⼯程。 但凡接⼿过⼀个相对复杂的项⽬，你就会理解，只要在功能上稍稍增加⼀点复杂度， 软件⼯程的复杂程度就会急剧增加，两者之间绝对不是线性的关系。对于我们⼤多数 ⼈来说，在真正开始⾯对这样残酷的现实之前，我们很少能够意识到将要⾯临的困 顿。从这个意义上讲，你要准备学习更多的软件⼯程的原则及调试技巧。如果你已经 认可这⼀点，或者，你是为数不多的、希望通过掌握⼀些技术来克服成长障碍的⼈， 那么本章就是为你准备的。 软件⼯程原则 以下是本章所涵盖的⼀些基本原则： 未来的软件使⽤者应该尽早， 尽可能多地参与到软件的设计及开发过程中 来； 建⽴⼀个初始的、简单的原型， 逐步完善； 编码与测试同步进⾏，不要⼀次测试太多的代码 （App inventor 中的块）； 开始编码前进⾏逻辑设计：对功能做纵向切割，对技术或实施的复杂度做分层 切割， 各个击破； 对代码块进⾏注释，以便其他⼈ （和你⾃⼰）能理解这些程序； 学会⽤纸笔来跟踪记录块的执⾏过程，以便于理解它们的⼯作机制。 如果能够遵循上述原则，你就可以节省时间，避免挫折，从⽽制作出优秀的软件。但 你很有可能做不到每次都依原则⾏事 ！有些原则看似违背常理。⼀种⾃然的倾向是， ⾸先有了⼀个想法， 假设你了解⽤户的需求，然后开始把若⼲个块拼在⼀起，直到 完成了想象中的任务。现在，让我们回到软件⼯程的第⼀个原则，在正式开始动⼿之 前，看看如何了解⽤户的需求。 设计要⾯对真实的⼈、现实的问题 电影 《梦幻成真》 （Field of Dreams ）中的男主⾓Ray听到了⼀个声⾳向他低语：“如 果你建好了，他们就会来。”Ray听从了这个声⾳，在爱荷华州的农场中间建了⼀个棒 球场，果然，在19 19年，芝加哥⽩袜队 （White Sox ）和成千上万个球迷出现在这⾥。 不过你现在必须明⽩，那个低语的建议绝对不可以⽤于软件开发。事实上，必须正相 反。在软件开发的历史中，充斥着各类“没问题”的伟⼤⽅案 （如：“让我们写个软件， 告诉⼈们开车到⽉球需要多长时间 ！” ）。⼀个优秀的 （同时也是极有可能获利的） 软件的真正⽬的是解决现实中的问题。想知道问题出在哪⾥，就要找到有问题的⼈， 与他们交谈，这就是通常被称作“ 以⽤户为中⼼”的设计⽅法，这个⽅法同样也可以 帮助你做出更好的应⽤。 如果遇到程序员，你可以问他们，在他们所写的软件中，有多少被真正交付到了最终 ⽤户的⼿中。结果会让你感到惊讶：即使是对那些伟⼤的程序员来说，这个⽐例也还 是太⼩了 ！许多软件项⽬驶⼊了问题的泥沼⽽终⽆见天之⽇。 以⽤户为中⼼的设计理念意味着尽早 尽可能多地替未来的使⽤者着想， 与他们交 流，这种思考与交流甚⾄应该在尚未确定⽬标之前就开始。⼤多数成功的软件都是针 对某个具体的⼈，试图解决他的特定问题，也只有这样，最终才能发展成⼀个伟⼤的 产品。 快速地创 软件原型，并展⽰给未来的使⽤者看 如果让最终⽤户阅读软件功能的说明⽂档，他们多半不会给出任何有效的回应，他们 不会对⽂档做出反馈。真正有效的⽅法是，让他们体验未来软件的交互模式，即软件 的原型。原型是⼀个不完整的、未经重构的软件版本，创建原型的⽬的在于充分体现 软件所具有的核⼼价值，⽽不必注重细节、完整性或漂亮的⽤户界⾯。拿出原型让未 来的使⽤者看，然后安静地倾听他们的反馈。 迭代式开发 在⾸次明确了软件的具体规格之后，采⽤迭代式开发。你可能很⾃然地倾向于将所有 组件和块⼀股脑地添加到应⽤中，然后下载到⼿机上看看它是否好⽤。举例来 说，“答题”应⽤，在缺乏指导的情况下，多数初学者会⼀次性添加所有的块：带有⼀ 长串问题及答案的块、浏览问题的块、检查⽤户答案的块，以及与每个逻辑细节有关 的块，所有的块未经测试就全部罗列在应⽤中，这种开发⽅式在软件⼯程中被称 为“⼤爆炸”⽅式。 ⼏乎所有的初学者都会采⽤这种⽅式。在旧⾦⼭⼤学 （USF ）的课堂上，当学⽣忙于 创建应⽤时，我经常会问他⼀个问题：“进展如何？” “我想我做完了，”他说。 “好