lAtitit.软件兼容性原理与实践 v5 qa2.docx Rapanui

 

Atitit.软件兼容性原理与实践   v5 qa2.docx

 

 

 

 

1. Keyword2

2. 提升兼容性的原则2

2.1. What 与how 分离2

2.2. 老人老办法，新人新办法，只新增，少修改，莫删除2

2.3. 计划赶不上变化，永远api修改也不可能整齐划一，反而带来不兼容的风险2

3. 兼容性的重要性与反面教材2

4. 架构and模块兼容性3

4.1. 粒度最小化，得到最好的灵活性3

4.2. 多套ui/xx模块，如何兼容3

4.3. 要是计划新的模块,老的模块可以不修改同步,推荐新的模型走好..3

4.4. 页面级,场景级配置,ioc配置3

4.5. 多语言的兼容性3

5. Api兼容性3

5.1. 创建新的api应该使用什么标准???4

5.2. 增加新api  而不是  修改旧的api4

5.3. Threadlocal4

6. 接口兼容性4

6.1. 新的接口去继承原来的接口，把新增的方法在子接口中声明。这样可以保持100%向前兼容4

6.2. 修改接口（应该发布一个新接口，固化老接口5

7. Web方面的兼容性（js，html）,相同源码不同项目的实现5

7.1. 15.1. 不同的项目与不同的实例启动5

7.2. 15.2. 不同的项目与实例配置文件6

7.3. 15.3. Web.xml怎么办？？6

7.4. 15.4. 跳转到同一功能spec的不同实现6

7.5. 15.5. 不同项目的同一功能就实现可以放在同一上级模块package下6

8. 数据库表兼容性7

8.1. 2. 扩展表模式7

9. 兼容性策略7

9.1. 3. 同时运行模式7

9.2. 3.1. 完美的后向兼容性8

9.3. 3.2. 虚拟机模式8

9.4. 3.3. 版本兼容性模式8

9.5. 4. 向前兼容(为升级预留足够余地）9

9.6. 5. “向前兼容”理念9

9.7. 6. 专门处理的软件列表9

9.8. Atitit.兼容性的“一加三”策略（不推荐）10

10. ref10

 

 

1. Keyword

如何提升软件与游戏api升级兼容性

 

2. 提升兼容性的原则

2.1. What 与how 分离

例如,ui ,使用dsl  html5 css来定义 ui ,不要使用native winform式的3gl语言

后端, 数据操作使用linq,sql  ,不要自己写一瓦代码,麻烦的.

 别的例如游戏,使用接口模式..定义一些api当dsl ,,使用实现来不同的实现..

 

例如cocos的定义场景,很麻烦的

// add bg

// var size = cc.director.getWinSize();

     this.bgSprite = new cc.Sprite(res.BackGround_png);

     this.bgSprite.attr({

         x: size.width / 2,

         y: size.height / 2,

     });

     this.addChild(this.bgSprite, 0);

 

使用dsl  html5 走容易的,还有标准的dw ide支持..可视化的ui设计.很方便的实现后端重构,不影响用户..

 

后端解析这个html dsl 定义,生成canvas对象走ok...

2.2. 老人老办法，新人新办法，只新增，少修改，莫删除

2.3. 计划赶不上变化，永远api修改也不可能整齐划一，反而带来不兼容的风险

3. 兼容性的重要性与反面教材

Java 与c#的兼容性走很好,win也很关注兼容性...

反面教材啊,也有啊..python3, cocos2d-js  v3.x的问题

 

4. 架构and模块兼容性

 

4.1. 粒度最小化，得到最好的灵活性

4.2. 多套ui/xx模块，如何兼容

如果因为历史原因，或者不同的实现项目导致有不同的ui模式，千万不要强行统一，会极大破坏兼容性。。

应该选定一个ui作为标准，并尽可能的像h5标准这类开放标准靠齐，遇到问题,好百度啊..补充的可以使用wpf标准.....

在新的文档是推荐新的标准就ok...老的api慢慢地使用的人走少兰..

 

4.3. 要是计划新的模块,老的模块可以不修改同步,推荐新的模型走好..

4.4. 页面级,场景级配置,ioc配置

例如,A模块使用了BCD三个模块,   p1界面使用了传统的a模块

目前有了新的的D2模块, 新的p2界面想使用d2模量,肿么办??使用页面级配置走ok..指定a模件使用bcD2模件走ok..不影响p1界面

 

4.5. 多语言的兼容性

例如,一个引擎,有多语言的

5. Api兼容性

 

5.1. 创建新的api应该使用什么标准???

简单的,使用世界流行的,标准化的标准走ok..

例如ui方面,使用h5标准,不足了补充使用wpf,,优点是资料多啊,你都可以不需要写api文档了,直接使用这个标准的资料走ok,资料足够..

后端语言api 了??? 使用流行的java ,js  ,可以补充c#风格拉..  C++ ,obj-c不推荐..

5.2. 增加新api  而不是  修改旧的api

最好是增加新的api。。这样不用调整老的api..添加测试工作...

当然一些很小的的调整可以直接调整老的api

一些必须修改老api的，可以变成api0模式，在新的api里面调用即可。修改bug模式。。

新api的命名可以采用 xxxV2 的模式这样就可以兼容老api。。

 

5.3. Threadlocal

 

它还有一些类似的方式用来使用，就是在框架级别有很多动态调用，调用过程中需要满足一些协议，虽然协议我们会尽量的通用，而很多扩展的参数在定义协 议时是不容易考虑完全的以及版本也是随时在升级的，但是在框架扩展时也需要满足接口的通用性和向下兼容，而一些扩展的内容我们就需要 ThreadLocal来做方便简单的支持。

简单来说，ThreadLocal是将一些复杂的系统扩展变成了简单定义，使得相关参数牵连的部分变得非常容易，以下是我们例子说明：

 

6. 接口兼容性

 

6.1. 新的接口去继承原来的接口，把新增的方法在子接口中声明。这样可以保持100%向前兼容

.接口和抽象类在C#和java中都差不多，这里提一下接口设计和抽象类设计的区别之处。如果你更改了一个接口的设计，比如增加了一个方法，使用你以前的代码的用户将不得不改变他们的代码，否则不能运行和编译。但是如果是一个抽象类，你可以提供一个含默认实现的方法，用户的代码则不需要改变。

 

批注：这个事实在Java和C#中都是一样的。但是，就接口和抽象类（即使包括骨架类）的选用依据可不是这个，这只是一个表现而已。再有，接口一旦发布了，就是你对外的一种承诺。之后即使是版本升级也不能再做任何改动，哪怕是增加新方法。那非要增加怎么办？如果同时提供的骨架类也控制在你的手里，可以通过在这个骨架类（其实就是抽象类的一种用法，骨架类实现接口，实际类再继承这个骨架类，骨架类中可以为实际类实现一些通用的、或默认的方法）提供一份新增方法的默认实现来达到目的。但这并不是明智的，因为版本升级时需要增加的新方法，往往是一些实实在在的干活儿的方法，在骨架类中给出一个默认实现往往没什么实际意义。更好的做法，是写一个新的接口去继承原来的接口，把新增的方法在子接口中声明。这样可以保持100%向前兼容，需要实现新方法的类属于伴随此次接口升级或日后要取实现的类。

6.2. 修改接口（应该发布一个新接口，固化老接口

公有的接口，一旦发布会后，就不应该改变的。如果你想添加新的方法，你应该发布一个
新的接口。。

有好几个

 

作者:: 绰号:老哇的爪子 （ 全名：：Attilax Akbar Al Rapanui 阿提拉克斯 阿克巴 阿尔 拉帕努伊 ） 

汉字名：艾提拉（艾龙），   EMAIL:[email protected]

转载请注明来源： http://blog.csdn.net/attilax

 

 

7. Web方面的兼容性（js，html）,相同源码不同项目的实现

7.1. 15.1. 不同的项目与不同的实例启动

通过不同的bat启动文件来实现。。

可以通过启动脚本来设置不同的实例

 

7.2. 15.2. 不同的项目与实例配置文件

参照mysql，通过制定配置文件来实现

 

7.3. 15.3. Web.xml怎么办？？

暂时没办法，可以通过jetty等可编程中间件来实现。。

 

 

7.4. 15.4. 跳转到同一功能spec的不同实现

比如游戏和点播系统的用户中心，ui界面就不同。。

可以使用查表法。。使用js，根据项目的id来跳转不同的功能ui加载，项目id在启动脚本里面传入。。  同一项目的不同实例只能跳转到相同功能，如果需要不同，在加个实例id判断吧。。

Prjid,instan_id,fun_implet

 

7.5. 15.5. 不同项目的同一功能就实现可以放在同一上级模块package下

重名问题，通过添加后缀_prj 来解决。。

如果项目很多，应该通过前缀来解决，这样好找。。

 

 

 

 

8. 数据库表兼容性

8.1. 2. 扩展表模式

 

9. 兼容性策略

作者::  ★(attilax)>>> 绰号:老哇的爪子 （ 全名：：Attilax Akbar Al Rapanui 阿提拉克斯 阿克巴 阿尔 拉帕努伊 ） 汉字名：艾龙，  EMAIL:[email protected]

转载请注明来源： http://blog.csdn.net/attilax

 

9.1. 3. 同时运行模式

 

　网上冲浪，用户用的最多的当然是浏览器，而Windows中内置的IE浏览器却着实让用户用的不爽，于是呼，在国内许多双核浏览器便大行其道。这 不，微软也觉得不好意思了，在Windows 10中新增加了一个浏览器-Spartan，这款整合了微软自家 Cortana 数字助理的新浏览器有桌面和移动两个版本，并深度融合了 Bing 搜索服务，让用户的搜索体验更加无缝。 

　　它将集成OneNote功能，方便用户进行记录，标注与分享，支持PDF文件显示，此外还有阅读模式等等的特性有消息称它将支持Chrome扩展程序。全新游览器开发代号“斯巴达”。 

不过消息显示，新老浏览器初期将会共存，一方面是避免突然切换造成兼容性问题，另一方面也可以给用户更灵活的选择，直到微软确定新浏览器足以取代IE，才会彻底转换过去。

 

9.2. 3.1. 完美的后向兼容性

9.3. 3.2. 虚拟机模式

9.4. 3.3. 版本兼容性模式

、

 

9.5. 4. 向前兼容(为升级预留足够余地）

9.6. 5. “向前兼容”理念

 

 

所 以对于已经处于垄断地位的公司，要居安思危，更是要敢于革自己的命，方能迎来更长久的成功。比如早期的英特尔公司虽然在存储领域占有垄断地位，但是其看到 CPU市场更长久的未来，毅然投入到CPU的研发之中，才有了今天的成功。但是同样是英特尔公司，在CPU方面抱着“向前兼容”理念，让Atom芯片背着 枷锁而跳舞，在全球嵌入式芯片的市场，让ARM的芯片独领风骚。同样微软在移动操作系统领域，背着兼容Windows操作风格的负担，让微软的移动操作系 统远远落后于专为移动设备而设计的iOS和安卓系统。相反谷歌却是让人称道，其在保持自己在搜索领域优势的基础上，不仅成功推出了安卓操作系统，目前又在 机器人、智能汽车、可穿戴设备等领域提前布局。

9.7. 6. 专门处理的软件列表

　我首先是从一个流行的游戏－模拟城市的开发者那边听到这样的事情的。他说模拟城市有个很致命的bug：它在释放完内存之后便立刻重新使用内存。在DOS环境下，这样的做法幸好不会是个什么问题。但是，在Windows下面，一个程序释放的内存，很可能会立即被另一个程序获取并使用，所以这样的做法是绝对不允许的。Windows开发团队的测试人 员测试了若干个流行的应用程序，并且搞定了它们，但是模拟城市一直出现问题。他们将问题反映给了开发人员。后者将模拟程序给研究了个彻底，找出问题的根 源，并添加了特殊的代码去检查模拟城市是否有运行，如果有运行的话，便将内存管理器运行为特殊模式，在此模式下，程序能够使用释放过的内存。 

　　这并不是什么稀罕的事情。Windows的测试团队是庞大的，而他们最重要的责任就是要确保所有人都可以顺利的升级他们的操作系统，不管他们安装了哪些应用软件，无论这些应用软件是否使用了不公开的旧系统接口还是依赖有问题的系统资源。实际上，如果你去查阅Windows注册表中的软件兼容性部分，你会发现里面有很长的一个被专门处理的软件列表。新版Windows会专门模拟一些旧系统中的bug使得这些软件可以正常运作。

 

9.8. Atitit.兼容性的“一加三”策略（不推荐）

 

“通过移除陈旧代码降低编译器维护成本，Java9 javac 将不再支持Java 1.5以及更早的代码。JDK9的“一加三”策略意味着该版本的javac会支持1.9/9, 1.8/8, 1.7/7和1.6/6 中的选项。该策略会在JDK10中延续。”

标题是我对新闻的解读。以下是我的理解。
这意味着，许多java最初的设计不合理会修改了。
将带来许多源代码级的不兼容性。
一些表达式，可能在早期编译结果false，以后可能变成true了。
比如String的==
也意味着Integer i = new Integer(0);Integer j = new Integer(0);
i==j以后也可能是true了。

 

 

10. ref

Java中ThreadLocal无锁化线程封闭实现原理 – 码农网.htm

atitit.提升兼容性最佳实践 p825.doc - attilax的专栏 - 博客频道 - CSDN.NET.htm

 

读《C# 和 Java 的比较》有感 - 从Java看编程 - ITeye技术网站.html

 

atiend