兼容性的一些思考

现状：
痛点：

• 兼容性问题不容易被发现:当前开发模式基本上都是基于安装模式开发。 出了问题基本上都是beta，生产等重要环境，非常严重。
• 降低代码质量:为了兼容性不得不写一些非常怪的代码，不利于可读性。
• 修改问题单，开发新特性的成本增加：修改任何问题之前都要思考是否会引入兼容性问题。
• 严重:代码上的一些不良实践。随着时间推移累积的兼容性问题必将成为NO1的质量问题。

平台目前处理：

• 见招拆招:基本依赖于开发人员的知识经验，缺乏规范和有效的工具和思路去识别和处理。
  兼容性升级手段：数据库脚步升级，app自动导入（本身也面临着兼容性问题）
• 代码处理:不断增加判断分支，不同的特性需要兼容的处理千差万别，无法梳理通用经验和自动化手段；易出错，或者无法处理，只能在使用体验上妥协。

一些基本原则
开闭原则:“开”指当原有的功能不满足新需求时，允许增加新的功能实现目标。“闭”指原有代码的修改是封闭的，即修改原有的代码对外部的使用是透明的。
这是一个处理兼容性问题的时候大多数采用的原则，大家都普遍意识到：“只要不动原来的东西，原来的代码的行为就不会出错”。
但是一味地新增也会带来代码难以管理的问题。我们在日常编码过程经常会遇到这样的情况：我开发了一个功能，当我基本验证完了之后会提交到svn。之后我可能又会进行优化，但是在优化的过程中又做了诸多改动，但此时发现由于优化而导致功能不可用了，这时候我们会选择回退到之前的“版本”。
“版本”这个概念我们也可以利用到我们平台的特性当中。我们遇到的兼容性问题，无非就是老的数据在新的程序上跑不了了，那我们为何不让老的数据在老的版本上跑，而新的数据在新的版本上跑？
切入点
为每个关键元素加version：做到这点并不难，选定一个发布的版本作为所有元素的基础版本号，创建的元素数据都带有这个版本号。以后该类元素特性有变更，则更换基础版本号，以后创建的元素数据就带有新的版本号。
如何做版本适配：
例如，Basemodel(01H2，没有继承模型属性actual_model_id)