关于复用，如何合理的复用这个事，想说清楚，真不是那么容易的事情，下面我说一个表是否复用的大致场景，以及我的感想。
有一个现有的表，然后有一个新业务，这个新业务和原来的表对应的业务很像（可想象空间很大），
那应该不应该复用，这里可能很难下定论，因为不知道这两个业务在长远看来是否是有共性，是否是可合并的，是否是互斥的，等等因素
如果仅仅是为了少建表这一个原因的复用，那么我认为是不可取的，这种情况下，可能表的字段满足当前的需求，但字段意义是有着千差万别的
很多情况下，为了区分这两个业务，可能会用type这类字段来区分一下，然后很大概率可能发生的情况是某一个业务需要调整，增加了一个字段，这时候另一个业务是完全不需要的，长此以往，可想而知这个表将来是什么样子，至少我看到这个表，以及对应的多个业务，是想吐的。
当然也有可能在刚开始复用的时候，是判断不出后面是这样的场景，那么在扩展表的时候，就需要有一定的决断力，表该拆的时候，一定要拆，不要为了省事，凑合着用。
往往实际开发的时候，不是这样，拆分可能会带来额外的工作量以及风险，工作量会因人而异，如果代码质量好，拆分的工作量可能会低些，然后另一个大家都不愿意触碰的是风险，如果因这些改动而造成了一些问题，那这个问题谁来担，公司中因为这个因素，使得大家几乎没有任何动力去优化当前现有的难看的代码，除非是公司文化使然，或者是领导明确了优化范围以及提供相应的测试资源，明确了此次需求的责任人，把这个事当成一个项目去做，可是，这样不对么？对么？
就我的意愿来说，我是希望在每次开发迭代中，把重构放第一位，从整体到局部，这样来说，是否复用的问题就变成如何设计当前的项目问题了。
可是反过来我又问自己，多出来的时间怎么办？风险谁来把控？
我自己尝试着回答，如果从长期来看，在一直保持着持续重构的基础之上，每次多出来的时间与风险，是完全可以抵消下一次迭代的开发周期节约的时间成本以及后期查问题的维护成本，
这个收益是延迟的，而且在一个本来就很乱的基础之上，首次做重构的工作，是很难的，如果后期不能持续这个传统，那么这一次艰难的重构工作会变得费力不讨好的事情。
还有一个点是，在重构的过程，最好是相关的业务人一起讨论，产品或者功能的性质，以后的演变的可能性，技术实现方案能支持到什么程度，等等，一方面有助于相关的业务人理解业务，另一方面也让PM能够重新审视自己的产品是否有问题。
写这个，也是因为公司代码中看到太多因为不合理的复用而导致的代码烂到不行，一边吐槽，一边梳理一下自己的想法。
0 comments:
Post a Comment