相信很多人都注意到XCode中, 有个Target的概念. 这在很多地方都有所体现, 比如打开一个工程后, 左侧的列表中有Targets一项, 而在工程界面的顶部菜单中, project里面也有多个涉及到Target的项目, 那么这个Target到底是什么呢?
Apple的人是这样说的:“ Targets that define the products to build. A target organizes the files and instructions needed to build a product into a sequence of build actions that can be taken.”
简单的理解的话, 可以认为一个target对应一个新的product(基于同一份代码的情况下). 但都一份代码了, 弄个新product做啥呢? 折腾这个有意思么?
其实这不是单纯的瞎折腾, 虽然代码是同一份, 但编译设置(比如编译条件), 以及包含的资源文件却可以有很大的差别. 于是即使同一份代码, 产出的product也可能大不相同.
我们来举几个典型的应用多Targets的情况吧, 比如完整版和lite版; 比如同一个游戏的20关, 30关, 50关版; 再或者比如同一个游戏换些资源和名字就当新游戏卖的(喂喂, 你在教些什么...)。
以上copy的。
这里不是要讨论如何制作这样的工程，而是选择做与不做。
最近的工作主题时维护制作两个不同版本的代码，相当是完整版和简版的两个项目。
现在我们的处理是放在两个不同目录，以前两个项目是由不同的框架组成，现在经过升级后，很多基础功能都是一样的，但也还是保留放在两个不同地方维护。我一边做一边在想，为什么一样的代码却要放在两个目录下，那时已经发现的bug，只有一个地方得到修复了，这边还是没有的。实现同样的功能，却使用了两份不同的代码和框架。
我理想的情况是，我们只有一个工程，这个工程应该就是一个完整工程，它包含了多个target，编译一次它同时或者单独输出各个不同版本的target即可。
但是，这次升级，我把iphone和ipad的代码和在一起，后来自己测试时，我却有些犹豫了。版本做成，iphone4.0运行的好好的，上ipad，崩了，上iphnoe3.0，起不来。于是代码中出现好多重复的这样的代码
If (isipad)
else
xxx
我开始在犹豫了。现在只是iphone和ipad放在一起，如果把两个不同版本的target放在一起，那也许更惨了。3.0编译的，要测试ipad的，iphone3，iphnoe4；4.0编译的同样也是。一次改动，所有的都要测试，那维护起来该有多么的小心翼翼，如履薄冰啊。而且代码也变得越来越脏了。
面对经常遇到复杂而又频繁多变的无聊小需求，把鸡蛋放到一个篮子里，或许真不是一个好的选择。相反的我倒是觉得也许现在没有将这两个工程和在一起是一个正确的选择。
取舍之间，我还是比较倾向于合并在一起维护。因为每一次出现一个小的适配，如果忘记两个地方都修改，出现一个又一个深藏的bug，最后应该是满目疮痍。
以前听说在做s60的软件都是单独几种设备适配一个版本，也就是说，需要维护同样的很多分代码，这对于我来说简直是噩梦。
不过做软件就是这样吧，该合的合，该分的还是需要分清楚的，一定要分清楚。
