问个开发的问题，(.net web app)

典

如果系统比较大，要分解成几部分给不同的人做，
又不希望让程序员获得整个系统，
可是系统模块间多少有关联

一般用什么方法来管理控制？

porcorosso

service？dll？

我瞎猜的

porcorosso

architect will come in good use in order to split modules and integrate them nicely.

大飞熊

找个牛人来design，不过那个牛人也会懂整个系统的。看你问的问题感觉你不太可能是这个人？

你这么做的目的是什么？怕程序员把你系统卖了？

典

是啊安全起见
尤其是外包给中国的人做得特别小心

kawara

把设计文档写细写好，每一模块严格定义输入输出。

也就是传说中的 design/coding by contract

典

要不开发阶段把一些重要模块以service的模式host,让程序员好做调试。比如做订单开发的最好是能获取产品／价格，但不获取关于产品价格的源代码。

kawara

调试用mock就可以了。

你这个小玩意不用整成service架构的

kawara

兄弟我感觉你弄不了这事

典

弄不好也没关系，就当学习了。
如果Mock 是不是将真实代码抽掉，程序员获得的只是mock过的？

kawara

典 发表于 2013-3-13 08:48
弄不好也没关系，就当学习了。
如果Mock 是不是将真实代码抽掉，程序员获得的只是mock过的？ ...

Mock里面没有业务逻辑的。

只是个简单的调用这个api，它给你返回点东西，也可以根据输入，返回不同结果。

double doRocketScienceCauculation(double x,double y,double z){

Return 3563257.76;

}

典

Mock我会，我的意思是，为了不让获取源代码，是不是应该把mock留着，已经做好的真实的源代码抽掉？

典

我搞混了mock在test project 里，如果发test project 似乎可以？

典

这些要是理顺，
是不是可以在澳洲接些小项目，分解外包给中国的程序员？做梦！

kawara

你给他们定义好子功能，输入，输出，各种share class 接口，让他们自己写unit test,好多工具可以根据接口生成mock

你需要做设计，分系统，整合测试

典

做什么都不容易啊，

wil

google ".net dll obfuscation"

无视

开发阶段rest/mocking是正确的方向。

source control方面，如果你们用tfs的话，你可能要把不同的team分到不同的solution和建立他们相应的tfs/windows group，他们属于同一个tfs project, 但用不同的folder，然后从folder这个level控制不同tfs/windows group的access permission.

用同一个tfs project的好处是很容易控制，build和deploy方面也不用做额外的工作。

开始阶段不要把他们分到不同的tfs collection里面去，否则你会做很多build/deploy重复的工作，agile上面很多东西也不能用。

有些common components如果需要被不同的team分享，可以做单独的solution，然后上公司内部的nuget,这样会解决build时dependency的关系。

典

无视 发表于 2013-3-13 09:50
开发阶段rest/mocking是正确的方向。

source control方面，如果你们用tfs的话，你可能要把不同的team分到 ...

谢谢
你这个要仔细参照研究一下。

典

wil 发表于 2013-3-13 09:47
google ".net dll obfuscation"

thanks
这个有意思。。

无视

典 发表于 2013-3-13 11:09
谢谢
你这个要仔细参照研究一下。

嗯，分不同的team到不同的solution虽然可以有效控制安全的问题，但会给build和release version management增加很多麻烦。

开始team之间要有效沟通，尤其是contract级别的东西，以后contract稳定之后可能就会好很多。肯定存在很多东西fail，但fail的不够快，直到build阶段才能反映出来，而不是dev的local env的compile阶段。

如果你们用nuget作shared components, 如何控制它的version，又没有现成的流程，如果nuget还有很多reference levels，就更加麻烦。

种种这些，如果之前没有这方面的经验，是你在design阶段无法预期的，这会让你们deliver的周期变长，违反agile精神。

如果security不是你们主要担心的话，我的经验还是用一个solution最有效，如果不是一个，也是要尽量减少solution的数量，即使同一个solution，如果deploy角度不会分属不同的box的话，尽量用name space来做逻辑区分，而不是不同的project，这样尽量让dependency tree作到扁平，会给你省掉很多release version control的麻烦。

现在说这个可能你没有实际的体验，等你们真正做起来，我们再交流吧，还是挺麻烦的。

linkspeed

用不同的solution，solution之间不共享project，
dll 里面会有版本号，用tfs build来自动更新版本号，每次build就加一个号

这样对于不是自己soultion里面的dll，就必须使用直接的文件reference或者进gac，
reference要使用specific version

因为开发到后来八成会出现某一个dll需要不同版本同时使用的情况。
这边更新了，但是无法向后兼容，那边还来不及更新。
然后你不得不允许多个版本同时存在。

joerkky

有种东西叫做SOA, 有另一种东西叫做NUGET

典

joerkky 发表于 2013-3-13 12:18
有种东西叫做SOA, 有另一种东西叫做NUGET

这可能也是个方向，我会注意这点。
只是我的出发点不完全为了把功能分离开来。开始阶段属于小打小闹的。以后看进度再说....