采购组织代码_您如何组织代码？

采购组织代码

How do we organize our code? Well, it all depends on the project and what we're trying to accomplish. We're also always learning. Our big C++ app builds differently than our lightweight C# stuff. However, for the most part we start with some basic first principles.

我们如何组织代码？ 好吧，这完全取决于项目以及我们要完成的工作。 我们也一直在学习。 我们的大型C ++应用程序的构建与轻量级C＃的构建不同。 但是，在大多数情况下，我们从一些基本的第一原则开始。

• A repeatable build
  可重复的构建
• • Obvious, maybe, but if you can't build it n times and get the same result, you may have some problems.
    也许很明显，但是如果您无法构建n次并获得相同的结果，则可能会遇到一些问题。
• Continuous Integration
  持续集成
• • When possible and appropriate, have builds automated and build mail sent out.
    在可能且适当的情况下，使构建自动化并发出构建邮件。
  • We started with building on every check-in, and for the most part we do that.
    我们从每次签入开始，在大多数情况下都这样做。
  • We added a daily build, so now we will build on every check-in, but there's a 5pm build also.
    我们添加了每日构建，因此现在我们将在每次签入时构建，但也有一个下午5点构建。
• Tools
  工具类
• • CruiseControl.NET - the goal being a company-wide dashboard.
    CruiseControl.NET-目标是建立公司范围内的仪表板。
  • NAnt -building
    南特建设
  • NUnit - testing
    NUnit-测试
  • NCover - code coverage, not formalized yet.
    NCover-代码覆盖率，尚未正式确定。
  • FxCop - For the obvious stuff, CLS compliance, etc.
    FxCop-适用于明显的内容，符合CLS等
  • NDoc - the shiznit. Use it to automate CHM file creation. That auto-generated CHM is then sucked into a larger 'prose' CHM.
    NDoc-shiznit。 使用它可以自动创建CHM文件。 然后，将自动生成的CHM吸入更大的“散文” CHM中。
  • libcheck - looking into it. Using it to measure API churn.
    libcheck-调查。 使用它来衡量API流失率。

As far as layout (picture above), there's no right way. We've got folks who've been doing builds since before Windows, so we have a little *nix-y style in a few things. Again, if it works, use it. I like:

至于布局(上图)，没有正确的方法。 自Windows出现以来，我们一直在从事构建工作的人们，因此我们在某些方面具有* nix-y风格。 同样，如果可以，请使用它。 我喜欢：

• source - for source. duh.
  源-用于源。 h
• tools - This CVS module is the source for any tools/utils the project needs. Shared between projects.
  工具-此CVS模块是项目所需的任何工具/实用程序的源代码。 在项目之间共享。
• install - XCopy deployment, it'd be nice. We do versioned MSIs for everything significant.
  安装-XCopy部署，很好。 我们对所有重要的事项都进行了MSI版本控制。
• test - Not Unit-tests per se, mostly larger projects for integration and regression testing.
  测试-本身不是单元测试，主要是用于集成和回归测试的较大项目。

As far as the build directory is concerned:

就构建目录而言：

Everything under build is 'important.' It kind of speaks for itself. Bin for bins, doc for the CHM.

正在构建的所有内容都是“重要的”。 这是不言而喻的。 Bin为垃圾箱，doc为CHM。

In source, we have:

在源代码中，我们有：

Every 'subsystem' has a folder, and usally (not always) a Subsystem is a bigger namespace. In this picture there's "Common" and it might have 5 projects under it. There's a peer Common.Test. Under CodeGeneration, for example, there's 14 projects. Seven are sub-projects within the CodeGeneration subsystem, and seven are the NUnit tests for each. The reason that you see Common and Common.Test at this stuff is that they are the 'highest." But the pattern follows as you traverse the depths. Each subsystem has it's own NAnt build file, and these are used by the primary default.build.

每个“子系统”都有一个文件夹，通常(并非总是)子系统是更大的名称空间。 在这张照片中有一个“ Common”，它下面可能有5个项目。 有一个对等的Common.Test。 例如，在CodeGeneration下，有14个项目。 七个是CodeGeneration子系统内的子项目，而七个则是每个项目的NUnit测试。 之所以会看到Common和Common.Test，是因为它们是“最高的”。但是在遍历深度时遵循的模式是：每个子系统都有自己的NAnt构建文件，并且主要默认使用这些文件。建立。

In this souce directory we've got things like build.bat and buildpatch.bat. The goal being that folks can get the stuff from source control and type BUILD and be somewhere useful. It's VERY comforting to be able to reliably and simply build an entire system. Recently I had to patch something I'd worked on 18 months ago, but that had used this principal. I did a Fet, did a BUILD and I was cool. We then used reflector and Assembly Diff to confirm that the patch surface area was minimal.

在这个源目录中，我们有诸如build.bat和buildpatch.bat之类的东西。 目的是使人们可以从源代码管理中获取内容并键入BUILD并成为有用的工具。 能够可靠，简单地构建整个系统非常令人欣慰。 最近，我不得不修补我18个月前从事的工作，但是使用了这个原理。 我做了一场Fet，做了BUILD，我很酷。 然后，我们使用反射器和Assembly Diff来确认贴片的表面积最小。

We DO build things in VS.NET, but for the vast majority of projects, we prefer a command-line build to get real repeatabilty. With .user files and per-user reference paths, I just don't trust VS.NET to do the right thing.

我们确实在VS.NET中构建东西，但是对于绝大多数项目，我们更喜欢使用命令行构建来获得真正的可重复性。 使用.user文件和每个用户的引用路径，我只是不相信VS.NET做正确的事情。

Junctions

交界处

Another thing we make a lot of use of are what we call Junctions. These are NTFS Reparse Points, also known as symlinks.

我们经常使用的另一件事是所谓的“连接点”。 这些是NTFS重新解析点，也称为符号链接。

In this screenshot of a standard DIR from the command prompt, directories show up as <DIR> while junctions say <JUNCTION>. These junctions point to other directories. But NTFS makes it transparent; you can CD into them, and even Explorer has no clue. Certainly, they can be dangerous, as you can clean out a directory and not realize that it's the authoritative source for something and is being referenced by other projects.

在命令提示符下的标准DIR的此屏幕快照中，目录显示为<DIR>，而结点显示<JUNCTION>。 这些连接指向其他目录。 但是NTFS使它透明。 您可以将它们刻录到其中，甚至资源管理器也一无所知。 当然，它们可能很危险，因为您可以清理目录而不会意识到它是某些内容的权威来源，并被其他项目引用。

You can download Junction from SysInternals. You can also use LINKD, that shipped with the Windows 2000 Resource Kit. In this screen shot, the relative SDK folder points to an installed version of our SDK. This allows our CSPROJ files to refer to our assemblies with relative paths, gives developers a lot more flexibilty, and makes the NAnt builds simpler.

您可以从SysInternals下载Junction。 您还可以使用Windows 2000 Resource Kit附带的LINKD。 在此屏幕快照中，相对的SDK文件夹指向我们的SDK的已安装版本。 这样，我们的CSPROJ文件就可以使用相对路径引用我们的程序集，为开发人员提供了更多的灵活性，并使NAnt的构建更加简单。

It also allows us to swap out different versions of things. For example, I could point the SDK folder to a previous (or future!) build of the SDK and build again. This flexibility comes with a cost though - complexity. People have to think a little more. Fortunately, our build guys are pretty savvy and will (shell script-like) go looking for preferred versions of things in standard locations and set up Junctions for folks. 

它还允许我们交换不同版本的事物。 例如，我可以将SDK文件夹指向该SDK的先前(或将来！)版本，然后再次进行构建。 但是，这种灵活性带来了成本-复杂性。 人们必须多想一点。 幸运的是，我们的构建人员非常精明，他们会(像shell脚本一样)去寻找标准位置的首选版本，并为人们建立Junctions。

翻译自: https://www.hanselman.com/blog/how-do-you-organize-your-code

采购组织代码