V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
that24
V2EX  ›  问与答

小弟 PHPER 一枚,求教下 api 如何做版本控制比较好?

  •  
  •   that24 · 2015-09-10 14:38:39 +08:00 · 2211 次点击
    这是一个创建于 3365 天前的主题,其中的信息可能已经有所发展或是发生改变。

    小弟 PHPER 一枚,求教下 api 如何做版本控制比较好?
    目前我采用的方法是通过继承,目录结构如下:
    modules
        usercenter (模块名)
            v1 (版本目录)
            v2
            v3
            ....
        item
            v1
            v2
            v3
            ...
    URL 示例:/v2/usercenter/xxx 会访问到 usercener 下面的 xxx 方法, v2 里面可以配置继承自哪一个版本,如果配置了 v1 会全部继承过来,然后 v2 做相应的重写即可
    这是小弟打算新项目这么只做,现在未重构前的项目是这样的,目录结构和上面一样, v1 和 v2 是不同的分支,所以当 v1 改动一个地方后要 merge 到 v2 ,还要 merge 到 v3...
    但是感觉都不太好啊,想请教下各位朋友是怎么做的哇?感谢每一个回复的小伙伴

    9 条回复    2015-09-10 15:27:04 +08:00
    msg7086
        1
    msg7086  
       2015-09-10 14:47:32 +08:00
    你都继承了为啥还要 merge ?不是直接会在子类里生效么?
    这个目录结构看着没啥问题啊。
    xing393939
        2
    xing393939  
       2015-09-10 14:49:34 +08:00
    为啥要用 merge , 2 个不同的版本应该差别很大了吧,如果差别不大就直接再原版本上做兼容,不一定非要弄出 v1 v2 v3
    that24
        3
    that24  
    OP
       2015-09-10 14:51:15 +08:00
    @msg7086 感谢回复,继承是新项目打算这么做的, merge 是以前的项目,能说说你们现在是怎么做的么?
    msg7086
        4
    msg7086  
       2015-09-10 14:52:39 +08:00
    @that24 我们?我们是谁?
    现在我不写 API 也不写 PHP ……
    cxbig
        5
    cxbig  
       2015-09-10 14:56:50 +08:00
    听楼主描述,应该是你们的版本间全是独立的,没有用到继承,做一个父类就好,把通用的方法、成员都放进去
    可以是:
    v1 <- abstract
    v2 <- abstract
    或者是:
    v1 <- abstract
    v2 <- v1
    (注,这里的 abstract 是逻辑上的父类,不是 abstract class )
    有特殊用法的子类可以改写相关方法 method 和 成员 property
    cxbig
        6
    cxbig  
       2015-09-10 15:03:36 +08:00
    至于 vcs ,看上去用 git 的可能性很大,给个建议:
    api
    |-v1
    |-v2
    \-v2
    在 abstract 里改了以后提交到 branch:api ,然后每个分支做 merge from api
    api-\
    \----\-v1
    \----\-v2
    \----\-v3
    不太确定你的“感觉都不太好”是不是说这样做 git 的 commit 结构看上去很乱
    如果是,这属于 OCD ,得治,药不能停
    that24
        7
    that24  
    OP
       2015-09-10 15:04:32 +08:00
    @xing393939 感谢回复, merge 是因为两个项目不同,当 V1 里面的某一个方法和 V2 里面相同时,如果这个方法出 BUG 了,你不可能去改两个地方吧,所以就改 V1 然后 merge 到 V2 ,不一定是有大改动才上新版本吧,不好处理兼容的也得上新版本,比如我们的情况:我们的 api 供 pc 和 app 端使用,现在 pc 端的商品要加仓库的功能,购物车会有调整,如果做兼容会降低代码的可维护性,感觉反而整得有点乱,所以我们起了 V2 分支版本项目,因为 app 无法及时升级,实际情况起新版本的情况还是挺多的
    msg7086
        8
    msg7086  
       2015-09-10 15:09:09 +08:00 via Android
    @that24 提取公共逻辑,然后尽可能重用代码才是真的。
    如果逻辑差异真的很大,那手改也不是不行啦。
    that24
        9
    that24  
    OP
       2015-09-10 15:27:04 +08:00
    @cxbig 感谢回复,思考了很久,你这个方法挺好,我再琢磨琢磨。 3Q
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1603 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 20ms · UTC 17:08 · PVG 01:08 · LAX 09:08 · JFK 12:08
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.