代码之家 › 专栏 › 技术社区 › Greg D

对于可重用代码库组织,我应该提出什么建议?

code-reuse version-control

Greg D · 技术社区 · 16 年前

在过去一两年里,我的组织已经开始慢慢地重新调整自己的业务模式,不再以产品为导向,而是以合同为导向。在过去的一年里,我被转移到新的承包业务中,以帮助灭火和完成订单。虽然这一年总体上是盈利的(因此,至少从一个角度来看,是成功的),但在6月份前后,我们有几个项目确实使我们今年的数字相形见绌。

圣诞节前我和我的经理谈过,他提到,虽然他不喜欢“验尸”这个词(我不知道这个词有什么不对,有没有生意人或经理知道?),他确实想在1月中旬的某个时候召开一次会议,整个合同小组将回顾这一年,试图找出哪些是对的,哪些是错的,以及我们可以采取哪些措施来提高盈利能力。

出于各种原因(如果有人要求,我将更详细地介绍),我相信我们的团队以及整个组织都将从某种形式的有组织的代码共享中受益。同样的事情被不同的人一次又一次地做,他们最终以不同的方式完成(和破坏)。我希望至少建立一个存储库,人们可以在其中获取执行特定任务的代码,并将该代码包括(或者,实际上,复制/粘贴)到他们自己的项目中。

对于一个至少有10-12名全职开发人员的团队,加上5-50名(非常)临时借调到合同组进行专门工作的兼职开发人员,我应该建议什么作为一个可行的公共源代码库?

开发人员将不会被迫使用此存储库。阻碍入口必须尽可能低,以便鼓励参与,否则就会失败被忽视。 可悲的是,这意味着任何需要 ClickOnce部署约为尽可能接近,这是非常不确定的。
我也许能够销售开源解决方案,但他们会被怀疑。所有开发人员都有VSS,公司董事已宣布VSTS在未来不可行。如果安装不太困难,并且许可证是自由的,我仍然可以尝试将VSTS服务器忍入实验室。
我想保护那些关心的人编写的任何共享代码不受那些不关心的人的影响。合同团队中至少有五分之一的同事完全忽视了常见的配置管理实践(比如在编写代码时签出代码)。
我们更擅长编写流程,而不是遵循流程。
不要假设最佳实践。

编辑:(回答问题)

也许收缩不是正确的术语。我们绝对拥有自己的代码资产。纸面上商业模式的一个重要部分(尽管在实践中还没有)是我们拥有我们编写的代码/项目,并且我们可以将它们重新销售给其他客户。我们的项目通常采取在公司现有的许多软件产品中添加一些特殊功能的形式。

6 回复 | 直到 16 年前

Nikhil 13 年前

Programming .NET Components - Jubal Lowy ).提倡干燥(不要重复)的编码原则。
在存储库中为所有可重用的代码库设置一个中央公共位置。这应该有可重用代码库的参考实现。
VSX Project System (VS.Net 2008) Code Project article on creating Project Templates
使用诸如MSBuild之类的构建自动化工具(它捆绑在VS2005及更高版本中)仅复制特定项目所需的组件。在IDE中将此部分作为构建设置的一部分(VS.NET2005和更高版本有很好的方法使用MSBuild设置编译前和编译后任务)
我知道开源解决方案存在阻力,但我仍然建议设置并使用一个连续的自动化系统,如 CruiseControl.NET 因此,您可以利用它从维护可重用代码库的中央存储库定期编译和测试项目。通过这种方式,可以快速检查对代码库的任何更改,以确保它不会破坏任何内容,它还可以帮助解决各种项目的版本问题。

希望这对你的布道有帮助,祝你好运:-)

我最近遇到了一组称为 Chuck Norris Frameworks -它们在NuGet上提供,网址为 http://nuget.org/packages/chucknorris . 您一定要查看它们,因为它们为您的ASP.NET项目提供了一些很好的模板。当然也可以结帐 Nuget .

Steven A. Lowe 16 年前

按主题组织,要求进行单元测试(特性级),以便签入/验收到库中;添加wiki以解释搜索内容/原因和

jmucchiello 16 年前

RogerV 16 年前

Maven已经解决了Java社区中的代码重用问题——你应该去看看。

Maven真的可以直接用于管理.NET程序集(我们将其与Flex.swf和.swc代码模块一起使用)只是.NET必须放弃使用Java工具,并且可能必须编写一个Maven插件来驱动msbuild。

Charles Gardner 16 年前

首先,对于代码组织,请查看Microsoft Framework设计指南,网址为 http://msdn.microsoft.com/en-us/library/ms229042.aspx 然后为您要创建的新框架创建一个中心位置源代码管理。设置一些默认名称空间和程序集,以便更清晰地分离,并确保每个人都获得每日生成。

Community CDub 8 年前

还有一点,因为我的商店里也有“共享代码”。

包装问题
常见的 构建工具能够

拥有这样一个“交付包单元”的主要兴趣在于 较少的 要尽可能部署的文件 ,以方便下载这些单元。

当一些审计团队想要检查我们的所有项目时,我们只需在他们的帖子上部署我们在生产机器上部署的相同包,除了他们将取消压缩源文件并完成他们的工作。

因为我们的源文件还包括编译它们所需的任何文件(例如 eclipse files ),他们甚至可以在自己的开发环境中重新编译这些项目)。

开发人员将不会被迫使用此存储库。进入壁垒必须尽可能低以鼓励参与,否则将被忽略
我们是一家规避风险的微软商店 :您可以使用所需的任何存储库
:这与这些包和模块中编写的代码的质量无关
不要假设最佳实践 :在打包可执行文件和源文件之前,不强制应用任何类型的静态代码分析。