项目移植点滴

15.1.29

       以前没接触过项目移植的工作。之所以会有移植是因为我们自主开发的底层平台变化了，底层平台从3.2一下子跳到了5.0，从版本号看得出来这是一次巨变，所以直接导致以前的做过的项目无法使用，但客户不会管换架构的问题，这是软件公司内部的事情，客户要的就是和之前一样的结果，如果锦上添花也可以，但不会给你一分钱，说到底移植是软件公司自觉完善自己产品的一个举动。移植的项目没有需求文档，有的只是一摊待的改造的代码，开发人员就像翻译官把日语翻译成汉语进行一次表面纹丝不动，而里面风起云涌的行动。

 

这个项目是一个战例项目（不要问我任何细节），由于是新手所以根本没有移植的方法，但通过一天的摸索初步总结出来：

0.参考已有的项目功能，任何项目都有相似功能点，里面涉及的技术自然相同

1.最好找同时熟悉两个平台的老手做一些技术指导，如：到底是重新做还是基于现有代码修改

2.移植主要功能，次要功能可以放缓

3.移植时的核心算法需要尽可能少的修改，与移植无关的类不要动

4.先移过去，再弄快

5.先移植核心功能

6.尽量不修改对外接口，而仅仅改变内部实现

 

15.1.30

7.想好对策后就要去做，边写边想才会发现隐藏的更多问题

 

15.1.31

8.下手干吧，空想与虚文都是扯淡。。。

 

15.3.10

9.老平台已有的API而新平台取消，则需要重新对此API进行手工封装，以此尽量减少对原有代码的改动