| 扬声器 |
抄本 |
| 奥罗拉·蒂芙尼·戴维斯 |
大家好，我是 Aurora Tiffany-Davis。我是 JMP Live 团队的软件开发人员。今天我想和大家聊聊 JMP Live 团队的软件开发工作。 |
| |
首先，我想让你想象一下开发软件是什么样子。如果你自己不是开发者，那么你脑海中的画面可能只是受你看过的电视和电影的影响。 |
| |
您可能会想象某个独自工作的人、某个非常聪明的人、甚至可能是天才，而且他们的工作流程非常简单。 |
| |
他们思考一个问题，编写一些代码，然后确保它能正常工作。而且很可能确实如此，毕竟他们是天才。 |
| |
如果我们都是 JMP Live 的天才，那么这个简单的流程应该很管用。但我们并非如此，而且我们生活在现实世界中。所以我们需要的远不止这些。 |
| |
首先，我们并不是单独工作，而是紧密协作，我们的流程包含多个步骤，力求确保我们生产的不仅仅是一些软件，而且是高质量的软件。 |
| |
我要指出的是，软件开发没有唯一正确的方法。不同公司，甚至同一公司内部，方法可能有所不同，但我将带你了解我们的流程。 |
| |
通过告诉您如果我要在 JMP Live 中开发新功能我会做什么。 |
| |
首先，在我坐下来写代码之前，我必须有一些这样做的需要。 |
| |
肯定有真正的用户遇到了真正的问题，他们在 JMP Lives 中发现了一些无法正常工作的软件……这些软件没有按照他们想象的方式运行， |
| |
这是一种委婉的说法，表示他们发现了错误或他们所请求的任何功能。 |
| |
我们在内部系统中跟踪这些请求。所以我要做的第一件事就是进入这个系统，找到一个与我的技能相匹配的高优先级问题，然后开始着手处理。 |
| |
接下来我需要进一步了解需求。我会和大家沟通，看看什么样的用户想要这个功能。他们会如何使用它。 |
| |
然后，我将在我的计算机上运行 JMP Live，并查看此功能在现有的 JMP Live 中如何适用。 |
| |
或者我可能会打开代码并查看新代码是否适合我们现有的代码库。 |
| |
一旦我觉得自己对需求有了相当好的理解，我就会开始设计。同样，我会和大家交流。我会问团队里的人：“你开发过类似的功能吗？你以前处理过这部分代码吗？” |
| |
我将与 JMP 的用户体验专家进行交流。 |
| |
我会尽量避免重复劳动。如果某个功能非常常见，并且并非 JMP Live 独有，例如将某些信息记录到文件中。 |
| |
这个问题已经解决了，过去已经有一千人遇到过这个问题。或许会有一个很好的开源解决方案。 |
| |
如果是这样，我可能会在仔细审查以确保其安全后使用它。 |
| |
还有很多内容需要讲解，很多 JMP Live 专用代码需要编写。所以我会写文章、图表， |
| |
描述我的方案，并确保团队中的每个人都对我的设计方向感到满意。然后我才会坐下来写代码。 |
| |
为此，我将使用集成开发环境，这是一种编写代码的工具，它具有很多花哨的功能，可以帮助您更高效地完成工作。 |
| |
现在我已经写了一些代码。在提交之前，我想先找出代码中存在的问题。毕竟我只是个凡人，所以第一次就写出 100% 完美无缺的代码的可能性很小。 |
| |
我将从寻找非常明显的问题开始，为此，我使用静态分析。 |
| |
静态分析不是在代码运行时进行检查，而是像检查刚写在纸上的代码一样。这类似于 Microsoft Word 中的拼写检查。 |
| |
拼写检查无法告诉你是否写了一本引人入胜的小说，但它可以告诉你是否漏掉了一个逗号。代码的静态分析可以做到这一点。 |
| |
一旦我发现并修复了这类非常明显的问题，我就会继续寻找不太明显的问题。为此，我们使用了自动化测试套件。 |
| |
这与静态分析不同，因为它实际上会运行代码。它会使用特定的输入运行一段代码，并期望得到特定的输出。我们为代码编写了各种各样的测试。 |
| |
我会坐下来为正在开发的功能编写测试。 |
| |
这真的很有用，因为坐下来写测试迫使我理清自己对代码具体应该如何工作的思考。此外，它还能防止将来其他人意外破坏该功能。这是一种及早发现问题的好方法。 |
| |
现在开始手动测试。我会在我的机器上运行 JMP Live，测试一下这个新功能，确保它能按照我预期的方式运行。 |
| |
我甚至可能会在 JMP Live 背后的数据库中四处寻找并跟踪记录、帖子、群组、用户和评论，以确保所有这些记录都按照我认为应该的方式写入。 |
| |
现在我谨慎乐观地认为我已经写了一些不错的代码，下一步就是同行评审。我希望我的同行能帮我检查代码，找出我可能遗漏的任何内容。 |
| |
我可能因为自己对某些事情一知半解，或者团队里有人掌握了我所不具备的知识而错过了一些东西。这一步通常对审阅者也很有帮助，因为他们可能会学到一些新技术。 |
| |
经过同行评审后，我们就可以实际提交代码或将其检入源代码存储库了。 |
| |
我们的服务器上有一个持续构建系统，它会监视我们签入代码。当我们这样做时，它会使用该代码执行大量操作。 |
| |
例如，确保正确的文件位于正确的位置，并以正确的方式命名等等。它还会返回并重新运行我们的堆栈分析，并重新运行我们的整个自动化测试套件。 |
| |
这很有用，毕竟我们只是凡人。有些人可能在流程的早期阶段忘记了做这些事情，或者自从上次做完之后，某些事情可能发生了变化。 |
| |
一旦代码通过持续构建，开发团队以外的人员就可以使用它。最先发现这一点的人是 JMP 内部的测试专业人员。 |
| |
他们会进行检查，可能会添加到我们的自动化测试套件中，也可能会运行一些手动测试。 |
| |
他们可能会研究软件在不同的操作系统、不同的浏览器等等上运行情况。他们会设想用户可能会做的一些疯狂的事情，然后观察会发生什么以及软件会如何响应。 |
| |
他们是我们流程中至关重要的一部分。他们非常有创意地思考，试图找出我们产品中的问题。 |
| |
一旦他们签字同意，该软件就可以在我们的下一个软件版本中被使用。现在让我来放大一下，向你们展示一下产品……整个流程。 |
| |
这其中涉及很多步骤，内容也非常多。我们真的要对所有代码都这么做吗？ |
| |
不管你信不信，我们确实这么做了，但这个过程规模非常大。所以，对于一个非常简单、显而易见的 bug，我们会非常快速地逐步完成这个过程。 |
| |
但是对于这个过程的每个步骤中非常复杂的新功能，我们都会放慢速度，花时间并非常小心地确保我们真的做对了。 |
| |
任何耗时耗力的事情都会对公司造成成本。那么，JMP 为何愿意在软件质量上投入如此多的资金呢？ |
| |
原因很简单，我们对自己的工作感到自豪，我们想要生产出好的产品。 |
| |
第二个原因就没那么理想化了。我们知道，如果我们的产品有问题，而我们没发现，客户就会发现，这对业务不利。所以我们希望尽量减少这种情况。 |
| |
需要指出的是，虽然 JMP 确实在软件质量方面投入了时间和金钱， |
| |
我们不像 NASA 那样投入那么多资金，所以我们无法保证完美。就像市面上任何一款软件一样， |
| |
您可能会发现 JMP Live 中的某些功能未按您预期的方式运行。如果您发现任何……建议， |
| |
我们诚邀您访问www.jmp.com/support ，并告诉我们您是否认为任何功能应该有所不同，或者您希望将来添加哪些功能。 |
| |
来自真实用户的真实反馈对我们来说非常宝贵，我们非常欢迎。今天我要分享的内容就到这里，希望大家能够享受Discovery的剩余内容。谢谢。 |
