随着项目开发的进行,在项目框架搭建阶段完成的共用控件到现在都做了不同程度的修改。这使我越来越感觉到共用没有预想的那么好。在项目的构建规划时我们想到的是共有带来了代码的减少,接口的统一。于是很多东西我们都尽量做到共用,实际上也是这样去做的。每完成一个共用控件或一段共用代码我都会想我这是在为其他开发人员编写代码。会为他们节省工作时间,提高工作效率,想到这便不由自主的为自己的工作而感到自豪。随着项目开发的进行,有些事情好像没有按照计划在进行,事情渐渐的失去了控制。摆到我面前的是共用控件与共用代码的修改,而这些新的需要的确又是合理的。于是一个接一个的新的功能需求被加入,代码也一次接一次的重构。有时候还是为它仍然能够工作仍然能为其他程序员提高工作效率而高兴,只是这种心情慢慢在减少,考虑更多的是共用代码的可读性,可维护性,效率等等问题。于是我将需求和控件重新进行了整理,做了一些分类,一些控件被拆分成多个控件,一些控件被合并成一个控件。这使用对共用有了一个新的认识:并不是凡是共用的代码就是好代码,就一定能提高项目的进程,共用带好处同时也带来的新的问题,如:共用代码的修改将面需要考虑更多的情况,效率也将是一个问题(有时文控件为满足多种情况而需要加入更多的代码),所以我们对待共用需要从多方面及发展的眼光去看。在利与弊之间去寻求一个平衡点。相信有了这些考虑项,共用代码会更能经受时间有项目的考验的。
我把自己的经验记录下来做成审查表,以备将来使用:
1. 共用代码有没有考虑将来需求的变化。
2. 共用代码是否功能明确目标单一(如果你的共用代码同进在做两件事或都更就需重新审视了)
3. 当有多个地方(每个地方有一些不需的求需)使用进控件时会不会在有些地方带来无谓的资源效率的浪费。
4. 你的共用代码是否与其他代码的耦合度很高,是否依赖于高变的东西。
如果基于以上都考虑了,那么请相信你的决定。