对于可重用的代码库组织，我应该提出什么建议？
在过去的一两年里，我的组织已经开始慢慢地重新调整自己的目标，转向不太以产品为导向的业务模式，而是更加以合同为导向的业务模式。 在过去的一年里，我被调入新的承包业务，帮助扑灭火灾并完成订单。 虽然这一年整体上是盈利的（因此，至少从某种意义上来说，是成功的，但我们有几个项目确实影响了我们今年六月份的业绩。
我在圣诞节假期前与我的经理交谈，他提到，虽然他不喜欢“事后剖析”这个词（我不知道这个词有什么问题，有商业人士或经理知道吗？），但他确实想在一月中旬的某个时候召开一次会议，整个合同小组将回顾这一年，并试图找出哪些是正确的，哪些是错误的，以及我们可以采取哪些举措来尝试提高盈利能力。
出于各种原因（如果需要，我将详细介绍）。相信我们的团队乃至整个组织会受益于某种形式的有组织的代码共享，同样的事情由不同的人一次又一次地完成，但最终会以不同的方式完成（并被破坏）。我想至少建立一个存储库，人们可以在其中获取执行特定任务的代码，并将该代码包含（或者实际上复制/粘贴）到自己的项目中。
对于一个至少有 10-12 名全职开发人员，加上 5-50 名（非常）兼职开发人员（临时借给合同组进行专门工作）的团队，我应该建议什么作为可行的公共源存储库？
答案需要一些文化信息才能获得合理的答案，因此我将在这里提供它，以及我对此主题的一些想法：
- 开发人员不会被迫使用此存储库。 障碍 条目必须尽可能低 鼓励参与，否则就会 被忽略。 可悲的是，这意味着 任何需要 额外的软件客户端 安装并运行可能会失败。 ClickOnce 部署大约为 我们已经尽可能接近了，但这是非常不确定的。
- 我们是一家规避风险的微软商店。我也许能够销售开源解决方案，但他们会受到怀疑。 所有开发人员都有 VSS，公司总监已声明 VSTS 今后不可行。 如果设置不是太困难并且许可证是自由的，我仍然可以尝试将 VSTS 服务器引入实验室。
- 我的一些开发同事关心编写高质量、可靠的软件，有些则不关心。我希望保护那些关心的人编写的任何共享代码，以免受到那些不关心的人的影响。 合同团队中至少有五分之一的同事完全忽略了常见的配置管理实践（例如在处理代码时检查代码）。
- 我们更擅长编写流程，而不是遵循流程。我几乎必须有某种形式的书面流程才能将其推销给我的经理。 我相信它必须是轻量级的、灵活的，并且由远程相关的工具强制执行，因为我的经理是唯一会阅读它的人。
- 不要假设最佳实践。我非常希望包括强制代码审查之类的内容，以强制在公共代码上使用静态分析工具（FxCop、StyleCop）。 然而，这提高了门槛，因为目前还没有以一致的方式执行此类实践。
我很乐意提供任何额外要求的信息。 :)
编辑：（回答问题）
也许签约不是正确的术语。 我们绝对拥有自己的代码资产。 纸面上的商业模式的一个重要部分（尽管在实践中还没有）是我们拥有我们编写的代码/项目，并且我们可以将它们转售给其他客户。 我们的项目通常采取向公司众多现有软件产品之一添加一些特殊功能的形式。
My organization has begun slowly repurposing itself to a less product-oriented business model and more contract-oriented business model over the last year or two. During the past year, I was shifted into the new contracting business to help put out fires and fill orders. While the year as a whole was profitable (and therefore, by at least one measure, successful, we had a couple projects that really dinged our numbers for the year back around June.
I was talking with my manager before the Christmas holiday, and he mentioned that, while he doesn't like the term "post-mortem" (I have no idea what's wrong with the term, any business folks or managers out there know?), he did want to hold a meeting sometime mid-January where the entire contract group would review the year and try to figure out what went right, what went wrong, and what initiatives we can perform to try to improve profitability.
For various reasons (I'll go into more detail if it's requested), I believe that one thing our team, and indeed the organization as a whole, would benefit from is some form of organized code-sharing. The same things get done again and again by different people and they end up getting done (and broken) in different ways. I'd like to at least establish a repository where people can grab code that performs a certain task and include (or, realistically, copy/paste) that code in their own projects.
What should I propose as a workable common source repository for a team of at least 10-12 full-time devs, plus anywhere from 5-50 (very) part time developers who are temporarily loaned to the contract group for specialized work?
The answer required some cultural information for any chance at a reasonable answer, so I'll provide it here, along with some of my thoughts on the topic:
- Developers will not be forced to use this repository. The barrier to
entry must be as low as possible to
encourage participation, or it will
be ignored. Sadly, this means
that anything which requires an
additional software client to be
installed and run will likely fail.
ClickOnce deployment's about as
close as we can get, and that's awfully iffy. - We are a risk-averse, Microsoft shop. I may be able to sell open-source solutions, but they'll be looked upon with suspicion. All devs have VSS, the corporate director has declared that VSTS is not viable going forward. If it isn't too difficult a setup and the license is liberal, I could still try to ninja a VSTS server into the lab.
- Some of my fellow devs care about writing quality, reliable software, some don't. I'd like to protect any shared code written by those who care from those who don't. Common configuration management practices (like checking out code while it's being worked on) are completely ignored by at least a fifth of my colleagues on the contract team.
- We're better at writing processes than following them. I will pretty much have to have some form of written process to be able to sell this to my manager. I believe it will have to be lightweight, flexible, and enforced by the tools to be remotely relevant because my manager is the only person who will ever read it.
- Don't assume best practices. I would very much like to include things like mandatory code reviews to enforce use of static analysis tools (FxCop, StyleCop) on common code. This raises the bar, however, because no such practices are currently performed in a consistent manner.
I will be happy to provide any additional requested information. :)
EDIT: (Responsing to questions)
Perhaps contracting isn't the correct term. We absolutely own our own code assets. A significant part of the business model on paper (though not, yet, in practice) is that we own the code/projects we write and we can re-sell them to other customers. Our projects typically take the form of adding some special functionality to one of the company's many existing software products.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
从声音来看，您有机会在“事后分析”期间提出一些解决方案。 我将创建一个演示文稿，概述您的想法，并在本次会议上展示它们。 在此之前，我建议您设置一些解决方案并在演示过程中进行演示。 一些要做的事情 -
宣传基于组件的编程（很好的读物是Programming .NET组件 - Jubal Lowy）。 倡导 DRY（不要重复自己）编码原则。
在存储库中为所有可重用代码库设置一个中央公共位置。 这应该包含可重用代码库的参考实现。
通过为常见场景提供项目模板并内置代码库，让人们可以轻松使用您的代码库。这样您的同事将拥有一致的模板来工作。 您可以利用 VS.NET 项目模板功能来实现此目的 - 查看以下链接 VSX 项目系统 (VS.Net 2008)，代码关于创建项目模板的项目文章
使用 MSBuild（捆绑在 VS2005 及更高版本中）等构建自动化工具来复制特定项目所需的组件。 在 IDE 中将这部分设置为构建设置（VS.NET 2005 及更高版本有一些漂亮的方法可以使用 MSBuild 设置预编译和后编译任务）
使用
我知道开源解决方案存在阻力，但我仍然会这样做建议设置和使用连续自动化系统，例如 CruiseControl.NET< /a> 以便您可以利用它从维护可重用代码库的中央存储库定期编译和测试您的项目。 这样，可以快速检查对代码库的任何更改，以确保它不会破坏任何内容，它还有助于找出各个项目的版本问题。
如果您可以将其设置在机器上并在事后分析期间将其作为可以采取的改进步骤的一部分进行展示，那么您应该更好地购买，因为您正在展示一些已经在工作并且可以轻松扩展的东西。
希望这对您有所帮助，并祝您好运:-)
我最近遇到了这套框架，称为 Chuck Norris 框架 - 它们可在 NuGet 上找到，网址为 http://nuget.org/packages/chucknorris 。 您绝对应该查看它们，因为它们为您的 ASP.NET 项目提供了一些不错的模板。 也一定要查看 Nuget。
From the sounds of it you have a opportunity during the "post-mortem"to present some solutions. I would create a presentation outlining your ideas and present them at this meeting. Before that I would recommend that you set up some solutions and demonstrate it during your presentation. Some things to do -
Evangelize component based programming (A good read is Programming .NET Components - Jubal Lowy). Advocate the DRY (Don't Repeat Yourself) principle of coding.
Set up a central common location in you repository for all your re-usable code libraries. This should have the reference implementation of your re-usable code library.
Make it easy for people to use your code libraries by providing project templates for common scenarios with the code libraries already baked in. This way your colleagues will have a consistent template to work from. You can leverage the VS.NET project template capabilities to this - check out the following links VSX Project System (VS.Net 2008), Code Project article on creating Project Templates
Use a build automation tool like MSBuild (which is bundled in VS2005 and up) to copy over just the components needed for a particular project. Make this part of your build setup in the IDE (VS.NET 2005 and up have nifty ways to set up pre-compile and post-compile tasks using MSBuild)
I know there is resistance for open source solutions but I would still recommend setting up and using a continuous automation system like CruiseControl.NET so that you can leverage it to compile and test your projects on a regular basis from a central repository where the re-usable code library is maintained. This way any changes to the code library can be quickly checked to make sure it does not break anything, It also helps bring out version issues with the various projects.
If you can set this up on a machine and show it during your post-mortem as part of the steps that can be taken to improve, you should get better buy since you are showing something already working that can be scaled up easily.
Hope this helps and best of luck with your evangelism :-)
I came across this set of frameworks recently called the Chuck Norris Frameworks - They are available on NuGet at http://nuget.org/packages/chucknorris . You should definitely check them out, as they have some nice templates for your ASP.NET projects. Also definitely checkout Nuget.
按主题组织，要求进行单元测试（功能级别）以签入/接受图书馆； 添加 wiki 来解释内容/原因以及搜索
organize by topic, require unit tests (feature-level) for check-in/acceptance into library; add a wiki to explain what/why and for searching
一个问题：你说这是一个咨询小组。 您拥有哪些代码资产？ 我认为您团队的大部分编码工作将由您的客户承担，作为您的雇佣合同的一部分。 如果您打算这样做，您需要绝对确定您的合同授予您对员工工作的权利。
One question: You say this is a consulting group. What code assets do you have? I would think most of your teams' coding efforts would be owned by your clients as part of your work-for-hire contract. If you are going to do this you need to make absolutely certain that your contracts grant you rights to your employees' work.
Maven 已经解决了 Java 社区中的代码重用问题 - 你应该去看看。
我有一位 .NET 开发人员，他为我们内部使用的 .NET 程序集设计了类似的东西。 由于没有类似的 .NET Internet 社区，因此该工具将仅访问我们公司网络中的内部存储库。 否则将会像 Maven 一样工作。
Maven 确实可以用来直接管理 .NET 程序集（我们将它与 Flex .swf 和 .swc 代码模块一起使用），只是 .NET 人员必须克服使用 Java 工具的困难，并且可能必须编写一个 Maven 插件来驱动msbuild。
Maven has solved code reuse in the Java community - you should go check it out.
I have a .NET developer that's devised something similar for our internal use for .NET assemblies. Because there's no comparable .NET Internet community, this tool will just access an internal repository in our corporate network. Otherwise will work rather much the way Maven does.
Maven could really be used to manage .NET assemblies directly (we use it with our Flex .swf and .swc code modules) is just .NET folk would have to get over using a Java tool and would probably have to write a Maven plugin to drive msbuild.
首先，对于代码组织，请查看 Microsoft 框架设计指南，网址为 http://msdn .microsoft.com/en-us/library/ms229042.aspx，然后为您要创建的新框架创建一个中央位置源控件。 设置一些默认的命名空间、程序集以实现更清晰的分离，并确保每个人都能获得每日构建。
First of all for code organization check out Microsoft Framework Design Guidelines at http://msdn.microsoft.com/en-us/library/ms229042.aspx and then create a central Location source control for the new framework that your going to create. Set up some default namespaces, assemblies for cleaner seperation and make sure everyone gets a daily build.
还要补充一点，因为我们在我的商店里也有“共享代码”。
我们发现这很大程度上是一个包装问题：
无论您正在生成什么代码或使用什么工具，您应该拥有一个通用构建工具，能够将您的源代码打包到“交付组件”中，其中包含用于实际执行代码，还执行文档（压缩）和源代码（压缩）。
拥有这样一个“交付包单元”的主要目的是尽可能部署更少文件，以便简化这些单元的下载。
构建过程可以通过 Maven 或您想要的任何其他（ant/nant）工具很好地管理。
当一些审计团队想要检查我们所有的项目时，我们只需在他们的帖子上部署与我们在生产计算机上部署的相同的包，除了他们将解压缩源文件并完成他们的工作。
由于我们的源文件还包含编译它们所需的任何文件（例如 eclipse 文件），它们甚至可以重新编译这些文件开发环境中的项目）。
这样：
开发人员将不会被迫使用此存储库。 进入门槛必须尽可能低，以鼓励参与，否则就会被忽略：它只是一个执行脚本来获取“交付模块”，其中包含他们需要的所有内容（maven 存储库可以是也用于此）
我们是一家规避风险的 Microsoft 商店：您可以使用您想要的任何存储库
我的一些开发人员同事关心编写高质量、可靠的软件，有些则不关心：这与编写的代码的质量无关这些软件包模块
我们更擅长编写流程，而不是遵循流程：其中涉及的唯一流程是打包流程，并且可以相当自动化
不要假设最佳实践：您不会被迫应用任何类型的在打包可执行文件和源文件之前进行静态代码分析。
Just an additional point, since we have "shared code" in my shop as well.
We found out this is very much a packaging issue:
Whatever code your are producing or tool you are using, what you should have is a common build tool able to package your sources into a "delivery component", with everything used to actually execute the code, but also the documentation (compressed), and the source (compressed).
The main interest into having a such a "delivery package unit" is to have as less files to deploy as possible, in order to ease the download of those units.
The build process can very well be managed by Maven or any other (ant/nant) tool you want.
When some audit team want to examine all our projects, we just deploy on their post the same packages we deploy on a production machine, except they will un-compressed the source files and do their work.
Since our source files also includes whatever files are needed to compile them (like for instance eclipse files), they even can re-compile those projects in their development environment).
That way:
Developers will not be forced to use this repository. The barrier to entry must be as low as possible to encourage participation, or it will be ignored: it is just a script to execute to get the "delivery module" with everything in it they need (a maven repository can be used for that too)
We are a risk-averse, Microsoft shop: you can use any repository you want
Some of my fellow devs care about writing quality, reliable software, some don't: this has nothing to do with the quality of code written in these packages modules
We're better at writing processes than following them: the only process involved in this is the packaging process, and it can be fairly automated
Don't assume best practices: you are not forced to apply any kind of static code analysis before packaging executable and source files.