这是我第一次面向对象的软件开发过程，过程充满了惊喜。
看山是山，看水是水
还记得自己第一次看到求导作业时，为自己的一个想法惊喜不已：在我眼里没有多项式，没有项，没有因子，只有函数，数字是函数，x是函数，+，-，*，^都是函数。当我上过研讨课后，我才明白：我还是太嫩了。我看到了多项式，想到了函数，这依然是“看山是山，看水是水”的直观思维，不够抽象。
看山不是山，看水不是水
在研讨环节，经过助教讲解后，我才恍然大悟，还可以这么做！由于项的规范性，完全可以用元组来表达，不同位置的数对应不同的因子，如幂函数与sin(x),cos(x)。而整个多项式，则可以用一个哈希字典来实现，用元组当作键，用系数当作值，这样实现又简单，还高效，便于化简。甚至对于某些三角函数公式，用元组的概念来表达也是很方便的。例如，sin(x)^2 + cos(x)^2 = 1, 可以表达为 ((0, 2, 0)->1, (0, 0, 2)->1) ==> (0, 0, 0)->1。而对于我建立的函数树，这些操作就不那么容易了。
如此看来，如果选择合适的数据结构来表达问题，往往能使问题得到简化。而选择数据结构时，要着眼于问题的本质特征，抽象特征，而不是表面特征。身为计算机专业的学生，我们必须训练自己的抽象能力。
看山还是山，看水还是水
当第三次作业时，由于允许函数的嵌套，所以上述元组的方法便不在可行。而我前两次建立函数树的做法依然可行。看来，不是自己第一次的想法不好，只是可以有更简单的做法处理。由此看来，重要的是根据不同的问题背景与限制选择合适的方法，优先选择简单的方法。
测试不规范，结局两行泪
记得第一次作业时，自己强侧错了两个点，都是多输出了一个*的问题，可是自己却没有测试出来。另外，自己第二次作业提交时就匆忙测了几个点，在中测 AC 后就再没有过了。结果悲剧发生了，自己的强测 WA 了一半，自己被砍了数十刀。面对测试数据，发现是自己符号处理错了。结果，就改了这一个bug，自己竟然全部 AC。回头看自己当初的测试数据，恰恰没有测试带负号的项。因为自己一时偷懒，竟然损失了50分，这可真是血的教训。在研讨课上听了老师对于测试的指导后，深感自己测试方法的简陋与不完善，没有系统的测试方法。看来以后要重视这个环节，因为这是软件质量的重要保证。
面向输入 PK 面向对象
感觉这三次作业写下来，自己的大部分时间都是在处理输入！由于自己在第一次作业时便使用了函数树的表达方法，致使后面两次通过建立函数树来实现求导的过程自己都写的很快，倒是每次的输入处理，让自己头大。记得第一此是正则爆炸的问题，后两次都是被规格书中反人类的规则所难倒。我想，软件的使用应该遵从最小惊讶原理。若一个用户使用了我们的软件，他发现x,+x, ++x都是合法输入，+++x却是不合法输入，他该是多么惊讶，另外，他还会发现，1，+1，++1，+++1都是合法输入，++++1却是不合法的，我想，无论这个用户多聪明，他若不看软件规格书，都很难想到这里面的原因吧。其他不在赘述。
经典就是经典
这是我之前没有获得经典的启发之前写的算法，真是惨不忍睹，递归还有栈。它到也能运行，就是如果支持作业规格中的各种输入限制，修改起来很是麻烦。
后来我发现了几个令人眼前发亮的短语，预处理，词法分析，语法分析，语义分析，突然感觉自己就知道自己该怎么写了。看来编译原理的经典知识就是经典，亲自实践过后发现，这个处理输入的框架真是好用，足够简单，足够有效，用来对付那些作业中奇怪的规则也很容易修改。
向经典致敬！