{财务资金管理}多币种资金.pdfVIP

{财务资金管理}多币种资 金 从它开始吧。 在编写测试的时候，我们总是为我们的操作设想最完美的接口（interface）。我们总 告诉自己这些操作在外界看来应该是个什么样子，尽管很多时候我们的设想并不能化为现实， 最好是从一种尽可能优秀的应用编程接口（applicationprograminterface ，API ）开始，然 后再倒着进行设计，这要比从一开始就把一切都搞得很复杂、拙劣而“现实”好。 下面是一个关于乘法功能的简单实例： ［我知道，我知道！这段代码有很多问题：公共域问题，副作用问题，货币金额用整数 来表示的问题，等等。别急，一步一步来。我们将这些毛病记录下来，然后继续前进。显然， ① 测试没有通过，但是我们希望测试能够尽快到达可运行状态（greenbar）。 ］ 当瑞士法郎与美元的兑换率为2:1 的时候，5 美元+10 瑞士法郎=10 美元 5 美元*2=10 美元 将“amount”定义为私有 Dollar 类有副作用吗？ 钱数必须为整数？ 我们刚才键入的测试程序甚至还不能通过编译。［我会在后边讲测试框架 （testingframework）JUnit 的时候解释在什么地方键入以及怎样将其键入。］修改这样的测 试非常简单。即便是编译后也无法运行，但为了使其能够编译通过，我们至少要做哪些工作 呢？我们存在以下四个编译错误：  没有Dollar 类  没有构造函数  没有 times(int)方法  没有amount 域 让我们逐一改正（我总是在寻找某种度量进度的数值化方法）。我们可以通过定义 Dollar 类来去掉一个错误： 一个错误已经解决，还有三个。现在我们需要一个构造函数，但是单单为了让测试能够 编译通过，它不必实现任何功能： 还有两个错误。我们需要 times()的存根实现（stubimplementation）。同样仅做可以使 测试程序通过的最少的工作： 仅剩下一个错误。最后，我们需要一个 amount 域： 好了，现在我们可以运行测试程序，结果如图 1-1 所示，失败了。 图 1-1 虽然测试失败，但有进步！ 可以看出测试程序没有运行通过（redbar）。我们在测试框架（在该例中为JUnit ）中运 行了这个作为开篇所编写的一小段代码，可以发现，尽管我们希望结果 “10”，事实上却 很不幸，我们看到的结果是“0”。 没有关系，失败也是一种进步。我们已经对这次失败有了一个具体的衡量，这要比只 模模糊糊地知道自己要失败的好。我们要解决的编程问题已经由原来的“实现多币种”转化 为 “让这个测试程序能够工作，然后让剩下的测试程序也能够工作”。问题已经比以前简单 多了，要考虑问题的范围也小了很多。而且，我们完全可以让这个测试程序工作起来。 你也许不喜欢这个解决方案，但是现在的目的不是获得最完美的解决方案，而是让这个 测试程序可以运行。我们将在做出理想的产品之前做出点牺牲。 ① Junit 测试工具运行测试时，如果测试全部运行通过，那么状态条是绿色的；如果存在没有通过的测试，那么状态条就是红色 的。本书作者大量使用包含 green 或 red 的字句，我们以后统一将其译作测试运行通过或没有通过。——译者注 下面是我所能想到的可以让测试程序通过的最小改动： 图 1-2 显示了测试程序再次运行后的结果。现在测试程序运行通过，可喜可贺！ 不过不要高兴得太早，致力于电脑编程的男孩女孩们，这一轮的工作还没完成呢！世界 上恐怕很难找到几个输入可以让这个功能有限、风格很差、近乎弱智的测试程序运行通过。 所以，我们在继续前进之前要把它一般化。记注，这一轮工作由下列的环节组成： 图 1-2 测试程序运行 （1）新增一个测试。 （2）运行所有的测试程序并失败。 （3）做一些小小的改动。 （4）运行所有的测试程序，并且全部通过。 （5）重构代码以消除重复设计，优化设计结构。