可能自己没有写代码的天赋吧，一场P2的考试就把自己打的原形毕露。
在理解上不难做到的“零钱两替”问题，在实际编程的时候却难以下手。
最直观的想法：根据零钱数执行对应次数的嵌套，判断是否符合相加为总钱数。
但是不行，因为零钱的数量是不确定的，这也意味着数组长度的不确定，我们无法写出一个不确定次数的for循环嵌套。
至少我不行。
于是想到了while，于是想到了递归。
还是不行，怎样都会出错。
怎么样都会出错。
最后尝试用贪心算法来解决，但问题在于我的贪心算法不够完备，也出现了各种各样的错误。
于是便开始拆东墙补西墙：这个例子报错了？什么问题？try-catch抛出异常来处理。那个例子报错了？什么问题？定义一个额外的变量来解决它……
说真的，就算这个最后的成品能通过测试，我也不会感到任何的高兴。为了最后的”通过测试“，我完全抛弃了时间复杂度与空间复杂度的限制。哪怕能通过，也是一个四不像的废品。算法复杂，变量冗余，宛如老太婆的裹脚布——又臭又长。
更何况，这块裹脚布，还没能完全通过测试。
为了解决其中的死循环问题，我定义了一个变量，使得程序递归1000次以上的时候返回。
也就是说，当需要递归1000次以上的时候，这个程序便毫无用处。
果不其然，系统测试组给出了一个很大的零钱数与总金额，我的程序完美的败下了阵来。
别的异常可以拆东墙补西墙。
但是无限不行，无限做不到就是做不到。
其实在写到一半的时候，我就大概知道这条路行不通。我没有大局观，就像是一个莽夫，拿着火把，在山洞中跌跌撞撞，受伤了就用树叶抹一抹，然后继续向前，殊不知山洞的旁边就有正常的走道。
但是我发现不了。
最后看了一下网上的解法，数量之繁多就不说了，而且大多简便，最多的也没有超过20行，最短的甚至10行不到就解决了所有可能出现的情况。
就仿佛是上帝视角，那些解法根本不需要走山洞，他们是坐飞机走的。
我，算不出来。
写这篇文章，算是给自己一个教训，永远不要自视甚高，永远不要沾沾自喜。
路还很长，还远没有到达可以劈山开路的境界，更何况是一块小石。
加油吧，自己。