|
锁定老帖子 主题：团队开发中代码安全的问题
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2006-03-07
非要这样不可的话，每个人负责的代码混淆加密成二进制的jar，供其他人引入。。。
|
| 返回顶楼 | |
|
发表时间：2006-03-07
vaja 写道 谢谢大家的建议。
在实际的开发过程中，我也认为过分限制对团队的开发效率会有很大的影响，真的是弊大于利。 richard 提到的“按照分层进行任务分解”也许真的是一个解决办法，但是现在的开发队伍还远远没有达到可以分层开发的地步。 虽然作限制有种种弊端，但是从技术的角度考虑，是否真的没法在以 spring + webwork 架构的项目中，限制各模块的负责人只能在自己的模块内进行开发，而不需要得到全部的代码？ 如果这种架构不行的话？那么有什么其它的架构可以实现这种形式的开发呢？ 问了这么多，其实我就是想找一些充分的理由来说服领导。如果各位能把自己接触过的代码管理的经验拿出来交流一下，也许能有所启发。 谢谢大家了！ 你限制每个人无法看到别人代码的理由和意义又是什么呢？ |
| 返回顶楼 | |
|
发表时间：2006-03-07
richard 写道 jack 写道 很难做到. 同时也不利于团队的发展.
确实很难做到，但是不明白为什么就不利于团队的发展？ 好像有人已经回答了这个问题了. gigix 说的 "所有人对所有代码负责。",就是团队对项目的全部的代码负责. 如果一个团队不团结,那么就不能称为团队. 而你们这样的做法,恰恰会导致各种猜疑和推脱.开发过程中如果出现各种衔接问题,那么每一个人会设法把问题推到另外一边去.因为他只看到自己的,他看不到其他的人的代码. 第二,如果团队成员有所变动,比如负责a的人走掉了. 抱歉的很,和a相关的人员的开发效率必然受到影响.就算团队里面有人接手,那么接手的人也会郁闷异常,因为在前面的开发过程中,负责a的人到底做了些什么事情,他一概不知. 做项目过程中,要预先考虑各种威胁的存在. 谁也没有这个本事也无法避免问题的产生. 你的这种做法,除非实施过程中无任何问题,比如程序bug,特别是相互衔接之后出现的bug,人员的变动等,这些都不要产生才有可能顺利进行下去. 重申下 "所有人对所有代码负责。" |
| 返回顶楼 | |
|
发表时间：2006-03-07
vaja 写道 谢谢大家的建议。
在实际的开发过程中，我也认为过分限制对团队的开发效率会有很大的影响，真的是弊大于利。 .... 问了这么多，其实我就是想找一些充分的理由来说服领导。如果各位能把自己接触过的代码管理的经验拿出来交流一下，也许能有所启发。 谢谢大家了！ 你说服不了..........,看的出来,你们领导很保守.或者说很小心谨慎. 这种方法如果硬要实行,也是可以的.只是人员的效率,公司的运转效率会降低不少而已. 估计你们领导也考虑到一点了. 当然更好的办法是保密协议了. 关于这点也要看你们公司本身的法律意识如何了. |
| 返回顶楼 | |
|
发表时间：2006-03-07
如果是几十人的大项目，每个小组只能看到自己模块的代码还是可以理解的。
如果细到每个人都只能看到自己个人的代码，效率就会太低了。 |
| 返回顶楼 | |
|
发表时间：2006-03-07
从业务逻辑的角度来看，做到“每个人只能看到自己负责的代码”应该可以吧？
代码最重要的还是逻辑吧？ |
| 返回顶楼 | |
|
发表时间：2006-03-07
jack 写道 richard 写道 jack 写道 很难做到. 同时也不利于团队的发展.
确实很难做到，但是不明白为什么就不利于团队的发展？ 好像有人已经回答了这个问题了. gigix 说的 "所有人对所有代码负责。",就是团队对项目的全部的代码负责. 如果一个团队不团结,那么就不能称为团队. 而你们这样的做法,恰恰会导致各种猜疑和推脱.开发过程中如果出现各种衔接问题,那么每一个人会设法把问题推到另外一边去.因为他只看到自己的,他看不到其他的人的代码. 第二,如果团队成员有所变动,比如负责a的人走掉了. 抱歉的很,和a相关的人员的开发效率必然受到影响.就算团队里面有人接手,那么接手的人也会郁闷异常,因为在前面的开发过程中,负责a的人到底做了些什么事情,他一概不知. 做项目过程中,要预先考虑各种威胁的存在. 谁也没有这个本事也无法避免问题的产生. 你的这种做法,除非实施过程中无任何问题,比如程序bug,特别是相互衔接之后出现的bug,人员的变动等,这些都不要产生才有可能顺利进行下去. 重申下 "所有人对所有代码负责。" 不采用'所有人对所有代码负责'就不团结了吗？那么没有xp的'所有人对所有代码负责'之前呢? |
| 返回顶楼 | |
|
发表时间：2006-03-07
richard 写道 jack 写道 richard 写道 jack 写道 很难做到. 同时也不利于团队的发展.
确实很难做到，但是不明白为什么就不利于团队的发展？ 好像有人已经回答了这个问题了. gigix 说的 "所有人对所有代码负责。",就是团队对项目的全部的代码负责. 如果一个团队不团结,那么就不能称为团队. 而你们这样的做法,恰恰会导致各种猜疑和推脱.开发过程中如果出现各种衔接问题,那么每一个人会设法把问题推到另外一边去.因为他只看到自己的,他看不到其他的人的代码. 第二,如果团队成员有所变动,比如负责a的人走掉了. 抱歉的很,和a相关的人员的开发效率必然受到影响.就算团队里面有人接手,那么接手的人也会郁闷异常,因为在前面的开发过程中,负责a的人到底做了些什么事情,他一概不知. 做项目过程中,要预先考虑各种威胁的存在. 谁也没有这个本事也无法避免问题的产生. 你的这种做法,除非实施过程中无任何问题,比如程序bug,特别是相互衔接之后出现的bug,人员的变动等,这些都不要产生才有可能顺利进行下去. 重申下 "所有人对所有代码负责。" 不采用'所有人对所有代码负责'就不团结了吗？那么没有xp的'所有人对所有代码负责'之前呢? '所有人对所有代码负责' 和xp无关.这个只是一种基本的团队管理办法. |
| 返回顶楼 | |
|
发表时间：2006-03-07
最多细分到模块，不同模块之间调用的话用MockObject。如果是软件公用平台需要保密的话，就混淆该部分的代码，只提供jar。
|
| 返回顶楼 | |
|
发表时间：2006-03-07
前提：
如果不需要在每个人的机器上都运行整个系统，每个人只负责自己的代码及其单体测试程序，所有的单元之间打交道的都是接口而且之前已经固定下来，或者有专人负责制定接口，那么这个要求是合理的，也是能做到的。 方法： 对于目录 chmod 770 对于文件 chmod 700 |
| 返回顶楼 | |
