问题标签 [project-organization]

我正在开始一个 Python 项目，并希望其中有 20 个或更多类。作为一种好的做法，我想将它们分别放在一个单独的文件中。但是，项目目录很快就会被文件淹没（或者当我这样做时）。

如果我将要导入的文件放在文件夹中，我将无法再导入它。如何从另一个文件夹中导入文件，并且由于它位于文件夹中，我是否需要以不同的方式引用它包含的类？

提前致谢

您会向“单人团队”推荐哪些工具或方法来保持井井有条？

我正在做涉及大量编码的研究，编写数百个一次性的 perl 脚本，在找到更好的方法之前使用的 C++ 二进制文件，以不同方式预处理的大量数据，其中一些新的预处理使旧方式已过时——直到我发现旧方式实际上更好，依此类推。我的工作本质上是一个移动的目标，因为我必须尝试很多事情，而且往往没有一个是完美的。

这不是一个完全混乱的情况，但也远非完美。在这种情况下，您会推荐一般方法吗？我确实使用SVN了我的代码，但不是用于不同版本的数据，因为它太大了。很难跟踪所有脚本和二进制文件，所以我总是评论它们，写下我是如何运行它们的等等。但我很好奇你是否还有其他想法。

（我在linux系统上工作。）

我一直在我的 Java 项目上运行一些指标，显然包之间存在很多依赖循环。我真的不知道如何将东西组织成包，所以我只是做了对我有意义的事情，这显然是错误的。

我的项目是一个神经网络框架。神经网络具有神经元，它们通过连接相互连接。他们需要相互依赖。但是，也有不同类型的神经元，所以我认为将它们都放在自己的“神经元”包中是个好主意。显然，连接不是神经元，所以它不应该在包中，但由于它们相互引用，我现在有一个循环依赖。

这只是一个例子，但我还有更多这样的情况。你如何处理这些情况？

另外，我读到包层次结构中较高的包中的类不应该引用更深的包中的类。这意味着包“nn”中的 NeuralNetwork 类不能引用包“nn.neurons”中的神经元。你们遵守这个原则吗？如果我将 NeuralNetwork 移动到 'nn.networks' 或其他什么？在这种情况下，它将引用同级包而不是子包。这是更好的做法吗？

假设我有一个列出 Persons 的网站，每个 Person 都有多个属性，一些是一对一的（姓名、地址），一些是一对多的（最喜欢的颜色、银行账户等）。

在我的业务层中，它的层次结构很好。

我如何组织这是我的控制器和视图？我应该有 PersonsController、FavoriteColorsController 等吗？都驻留在同一个命名空间和文件夹中？或者我应该只拥有一个具有许多操作的 PersonsController，例如 IndexFavouriteColors、UpdateFavoriteColor 等。这两个选项都不完全正确。第一个没有表明 FavoriteColors 是 Person 的子级，并且只能在人的上下文中使用。第二个将创建一个巨大的 PersonController。

当然，观点也是如此。最好的就是拥有

• 视图/人员/index.aspx
• 视图/人员/details.aspx
• 视图/人/等
• 视图/人员/FavoriteColors/index.aspx
• 视图/人员/FavoriteColors/details.aspx

在这个例子中，我只为 Person 提供了几个一对多的属性，但实际上有很多 (10+)，因此增加了对清晰度的需求。

谢谢。

我们的应用程序中有很多功能可以非常具体地描述为一个模块。通常有某种设置对话框，然后当用户单击确定时，它会配置一个进程来运行并运行该进程。有时他们更投入，用户会打开新对话框并在对话框上工作一段时间，做许多对底层数据库进行更改的事情。

我通常会得到几个标准课程

如果我有更多端到端模块，它可能是 WorkerPanel.cs WorkerData.cs SetupOptions.cs（面板状态在运行之间保持）Lib/WhateverBackendStuffINeedToSupportModule ApiWrapper

现在每个都有文件夹：

如您所见，一切都真正展开了。对于 50 多个模块，这些文件夹并没有真正组织起来。即使按子系统将它们分解，它们仍然是一团糟。将所有内容放在一起以便所有内容都按功能而不是类类型分隔会是糟糕的设计吗？

你如何组织你的课程，有什么优点/缺点？

我想知道组织大型 C 项目的最佳实践是什么。这是一个专业项目，而不是开源项目，可能存储在 Git 存储库中。事情应该如何排序？结构应该去哪里？什么时候应该使用附加到结构的函数而不是使用结构作为参数的函数？

在布局项目中的文件方面，应该如何组合？什么命名约定最合适？

这是我在很多很多公司都遇到过的一个问题：QA 团队应该向开发组织报告，还是相当于公司层次结构中的开发？

我们理解默认和通常推荐的 svn 存储库组织，如果有多个项目，是这样的：

我们的项目有很多相互依赖，这需要在它们之间广泛使用svn:externals，考虑到我们不做 dll 引用内部项目，我们更愿意查看它们的源代码而不是使用二进制文件。

过多地使用外部，在分支存储库、同步更改时，可能会变得复杂且容易出错，因此团队根本不信任这个解决方案。

因此，一位团队成员提出了一些我们都认为这可能是更好的解决方案：将所有项目放在同一个主干中。

起初，我们认识到这种方法存在一些问题，但总的来说，我们同意这些问题是基于我们很可能从未经历过的假设情况。

您是否看到我们在使用此解决方案时可能遇到的一些严重问题？

通用组件是由一个组创建和维护并由多个组使用的库或其他一些代码。

我们遇到的一些问题是：

• 用户不会报告组件的问题。
• 用户构建组件的变通方法以满足他们的需求。
• 他们打破与主干版本的兼容性只是为了满足他们的最后期限。
• 用户最终会编写自己的（不太健壮的）解决方案，因为他们认为这样更好。

您的组织如何处理通用组件？

我的想法：

• 将组件视为开源项目，并要求团队提交补丁。
• 完全不允许对代码进行自定义修改。
• ...

我目前正在从事一个范围非常大的项目，但是对于 C++ 来说相对较新并且来自 Java 背景，我不确定最好的方法。

我想要一个类似于以下的目录结构：

目前，我在 Engine 目录中有大量 .ccp/.h 文件。当我将它们移动到相应的文件夹并尝试将它们绑定在一起时，我只会得到与未定义类相关的编译错误页面。一些善良的灵魂可以帮助新手指出正确的方向吗？