关于跨平台项目代码及管理

cokeboL

个人觉得，跨平台的代码，不如就一个平台一份代码
实际情况是一份代码，靠一堆宏之类控制编译的代码，
我觉得这样不好，尤其是项目很大的情况，代码可读
性降低，码农眼花缭乱。项目还经常要借助代码外部
的make、批处理等进行配置、管理，随着项目的日积
月累，文档更新跟不上、人员更替等因素，项目维护
和开发的复杂度大大增加。
与其维护一份复杂，不如项目开始的时候就一个平台
一份，清晰明了，做哪个平台就在哪份代码搞，同时
要做几个平台的，涉及平台相关的接口都要单独加，
平台无关的代码，对比一下copy过去就是了。

个人观点

linux_c_py_php

额, 你愿意也可以, 和宏替换没什么区别, 就是看着干净罢了.

cokeboL

回复 2# linux_c_py_php


遇到的问题是，公司项目代码都是ios、win32、android三个平台，
前人做完项目，文档不改，很多项目，要移植，主要工作就是编译
相应的平台，编译通过了就差不多完成了，但是，资源、批处理，
各种不给力，流程是win下面打出资源，运行起来，然后再编其他
平台的，结果，win OK了，其他的平台，死活跑不起来，找不之前
的人。。。尤其是那种资源不行的情况，浪费大量时间

cokeboL

回复 2# linux_c_py_php


最近几个同事，一个项目为了编译通过，画上几周时间，最后打出的包，还不敢确定是否没bug

而这些项目，之前都是发布过的

cokeboL

回复 2# linux_c_py_php


    管理搞不好，坑死后来人

txgc_wm

个人感觉做到一份代码还是挺好的，主要是要完善文档。即便之前开发的人员走了，其它的开发人员也好维护。

cokeboL

回复 6# txgc_wm


    实际情况是：按照项目Readme，肯定不行。。。

evaspring

那说明代码封装的不好

linux_c_py_php

俺觉得代码质量是主要的。。。 人走人来应该是很正常的.. 关键是后来人看代码能不能看懂..

cokeboL

回复 9# linux_c_py_php

看懂不是问题，问题是浪费时间，如果各平台相关配置、代码分开放，项目新增花费的时间不会多，像我之前说的不同平台
接口反正都要单独加，相同的地方对比一下copy过去，但是放一起，文档没人跟进，后期，为了编译通过，就花上几周。。

比如，android项目，so编译出来了，apk打好了，资源文件一大堆flash、xml，之前发布过的版本，文档里没说用哪些资源
用错资源，比如资源文件名相同但是内容可能不一样，就跑不起来或者跑错