夜深了，适合思考。

回顾与反思

自三四月份其至今，做了两三个任务。在这期间，有收获也有不足，有进步也有值得思考的地方：

• 安排完成一项任务A以增强某一功能，总共有多种数据格式a1,a2,a3。因为本人是进行平台开发工作，需要在源码的基础上添加一个新的变量，在完成a1，a2两种数据格式的线下线上测试后，继续着手a3数据格式的线下向上测试。但是，出现了个问题：线下能够顺利测试完成，线上并不能完成测试，因为新添加的变量并没有进行成功赋值。经过不少时间（三四天左右）的查找以及leader的提醒，最后在该数据格式所对应的类中发现了原因。原来，该数据格式对应的类通过writeObject()/readObject()对成员变量进行序列化和反序列化操作。如果，我们只是在该类的构造方法中完成对新添变量的赋值，但是并不考虑在writeObject()、readObject()方法中进行相应操作，自然而然并不能正确的对数据进行赋值。另外，我的工作是对原来功能进行功能增强。我最开始的做法是，通过继承原有的类对所要增强的方法进行扩展与完善。虽然没什么工作难度，但是却带来了不足。原有的方法或多或少的都会调用本类的私有方法，子类如果想在不改变原有代码逻辑的基础上进行功能增强，难免需要将父类方法中使用到的私有方法复制到子类中。一方面，复制后会使你的项目看起来乱糟糟的，缺乏整洁，另一方面，在该类所在的项目进行版本更新时，该类中的逻辑很可能也需要进行替换与更新，这无疑需要花费更多的时间与人力去维护该部分代码。很明显，这个并不是我们想看到的。因为，我当前这个任务是增强任务功能，我们可以使用包装类来完成这个功能。在包装类中引用所要增强的类，并添加合适的逻辑与变量，在所要增强的方法中进行扩展与完善。
• 这几天安排了一个验证任务。需要验证功能A在版本2中是否可以使用。需要说明的是，功能A在版本1中引入，在版本2中完全移除了。基于此，我将功能A的代码完全复制粘贴到版本2的模块中，并对缺少的方法、类、变量等进行增加与替换。看起来，这个是个很可行也很简单的方法，但是，这却是错的很离谱。先抛开版本更新后类重构的逻辑与细节变化不谈，将新版本的类回退旧版本的类的做法本身就是不合理的。另外，即使缝缝补补后能够保证程序编译通过且能够运行，但是，也不能保证其内部的运行逻辑就是合情合理，没有问题的。这个时候，我们需要明确一个事：当前功能A是为了干啥的？他的执行流程是怎么样的？在新版本中，功能相似的代码他的执行流程是什么样的？能否在两者间找到共同点？明白了这些事之后，这个问题相信也就迎刃而解了。

总结

在近期的工作当中，发现学会了很多东西，也明白了自身的不足以及需要改进的地方：

• 阅读代码要细心。第一个例子的readObject/writeObject方法就是一个很好的例子。当前两种数据格式都能够进行线下线上测试时候，唯独第三种数据格式却出现了问题，在底层逻辑及方法调用的逻辑相同时候，就要考虑考虑是否是第三种数据格式类中定义了一些东西导致的。很明显，在这个例子中是这样的。
• 抓住重点。第二个例子验证功能就能够说明这件事。在一个项目中，该功能也许与其他功能具有比较大的区别，但是其底层逻辑应该都是相似一致的。从这点触发，我们要考虑考虑，在新版本中能否找到相关的代码逻辑，并根据其代码逻辑完成该验证功能的重构工作。
• 平台开发思想的逐步了解。在我刚接触刚工作的时候，我认为，对代码的修改可以直接在源码的基础上进行，这样既省事也比较简单。很显然，这是不对的。在我们开发的时候，需要考虑到项目版本更新迭代的问题，以及后期维护的成本问题，需要在最大限度上不动源码的基础上进行修改与增强。共勉。