江苏龙网

  1. 首页 > 生活 > >

C++ 不同工程中都会用到的公共类咋管理

我觉得你可以考虑自己写/自己包装一个引用工具……这事不管bash还是python、ruby都能很好的完成。例如：写个小小的配置文件，指明当前项目的编译依赖中各公共库分别是什么版本。公共库部分可以交给独立svn仓库去管理。写个小小的脚本，编译前先执行脚本根据配置文件checkout相应的公共库版本后再编译。具体可以参考类似js的webpack那套办法。
■网友
一般项目开始的时候接口修改频繁是正常的，这个时候一般会存在一些技术难点或需求的不稳定，随着项目的推进对需求的把握会越来越准确，接口就稳定下来了，前提是要及时重构，要舍得推倒重来，如果为了兼容老代码而妥协，那问题遗留下来到项目规模大了就会成顽疾，想改就很麻烦了。我喜欢的做法是把老接口先留着，重新写新接口，新代码用新接口，然后慢慢改使用老接口的代码，改的这段时间也不影响项目的编译，改完之后再把老接口删除，这样就可以完美过度。svn的代码最好要保证能编译通过，原因很明显了。把svn设置成文件需要加锁才能修改(还是默认就是这样？我忘了)，这样你改的时候别人就不能改了。上传前更新到最新代码编一遍，通过了再上传。要保证svn的代码可用，还可以用持续构建工具，我一直在用免费的叫hudson，可以和svn绑定。当svn一有变动时他就把整个项目都编一遍，有编不过的地方就给你发邮件，邮件内容就是编译错误信息和是谁上传的代码导致的。配置好后就不用管了，最好让它独占一台电脑，你要做的就是上传代码然后过一会结果就到你邮箱了，用foxmail什么的在后台挂着等就行了。我让hudson在每次编译后运行我的打包脚本，这样只要有人更新代码就会自动生成一个软件安装包，测试人员直接拿去测试，非常方便。不过要真的解决这种问题我觉得还是通过设计手段。除了接口本身的耦合度之外公共类的身份也有很大影响。比如你的公共类属于底层工具，有个strcpy的接口，那这个就没法弄了。所以公共类最好是面向抽象需求的，尽量隐藏技术细节，越抽象越好。极端一点的例子，如果你的接口名称包含string、file、host这样的技术性词汇，就可以考虑下是不是要把这些接口再聚合一下。
■网友
提供一个解决思路：step1. 给你的公共类们编写单元测试，覆盖你在不同的项目的调用场景。step2. 给公共类所在仓库设置一个 post-commit hook，每当更新公共类，就自动编译执行单元测试代码，如果单元测试不通过，SVN 会提醒你。手机党，未验证可行性。当然，如果都做到这份上了，用 @多多 提到的持续集成效果更佳，通过设计手段解决问题最彻底。


    推荐阅读


    上一篇：防疫■“神器”扎堆！校园防疫大升级

    下一篇：#诈骗#斩断诈骗团伙“黑手” 扬州警方三级联动