编码实践：您对170万LOC项目有何看法？

Question

我正在听小组讨论，其中一个人提及他们的'引擎'不是1.3，但现在是170万行代码。这吓到我了。我无法想象行数，模块数量等等。我一直认为C ++不像其他语言那样处理模块。我觉得大型项目难以管理，并且倾向于合理地保持代码行。当我达到10k线时，我感到不舒服。我无法想象20k，50k，500k或100万的感觉如何。

在开发和维护这种规模的项目时，您有哪些做法？

Answer 1

一百万行代码超过了大多数凡人可以将它们全部保留在脑海中的点。这意味着团队成员将携带系统的不完整心智图，这可能使设计讨论变得困难。

为了减轻多种不完整的理解，您需要以适当的一组架构图的形式提供地图。这些通常包括系统架构的非常高级的框图，更详细的关键部件的低级图，以及可能的序列图，用于描述适当详细程度的关键交互。在讨论系统时，将这些图表触及可以帮助团队“在同一页面上”。

'子系统图之间的依赖关系还可以指出需要清理的混乱区域（“为什么持久性框架的位依赖于UI？！？”类型）。如果你能想出一种自动生成这些图表的方法，那就最好了。 Graphviz可以成为你的朋友。

Answer 2

  

在开发和维护这种规模的项目时，您有哪些做法？

分而治之，因此没有这样规模的整体项目。

Answer 3

  

在开发和维护这种规模的项目时，您有哪些做法？

嗯，那就是你从开发人员发展成为架构师。

对于大型软件项目，项目负责人的关注不应该在实施时缩小，而应该在结构层面上：正确和正确地模块化您的组件/库，很好地将它们分离，利用设计模式。

Answer 4

对我而言，它不是线的数量，而是设计的模块化程度，模块封装的程度。在某一点之后，如果我可以放大模块，找出它的设计，编写功能和修复错误，那么代码行数无关紧要。可以说我没有使用超过100万行代码的系统。

Answer 5

那是什么类型的引擎？如果它是一个游戏引擎，它肯定模块化为图形，声音，物理，地图处理和许多其他模块。每个模块肯定包含几个子模块，即Graphics分为Font-Rendering，Effects，GPU特定部分等。

Answer 6

我想这取决于。你可以给一个坏厨师提供相同数量的食材（即很多）作为一个好厨师，坏厨师会给你一些让你呕吐的东西，而优秀的厨师可以让它味道好，容易消化。

我没有想到一个项目的行数，而是（正如你已经想到的那样）项目本身的可维护性。只要项目模块化并且重构得很好，它就不会太糟糕。

因此，为了回答您的问题，我用来维护大型代码库的实践与维护任何大小代码库的实践相同 - 我会考虑将自动构建与高代码覆盖进行集成（最好使用系统级测试） ），包括帮助您具有可读性的工具（例如检查式）和没有重复的代码（例如猿猴）以及诸如此类的东西。

如果项目继续增长并且您获得了大量的行并且您正确地开发了代码库，我想这只能意味着您的客户很满意并希望获得更多功能。

Answer 7

  

在开发和维护这种规模的项目时，您有哪些做法？

管理大型软件项目有很多想法，显然它在很大程度上取决于项目的类型：

• 资助软件开发（可能涵盖公司正在贡献的一些开源项目，比如Eclipse），
• “爱好者”软件开发取得了巨大的成功（想想Linux）。

资助软件开发通常倾向于从一开始就使用正式流程，其中“业余爱好者”项目倾向于仅采用所需的实践来解决绘制点。

正如其他人所指出的那样，这种规模的项目必然是团队的努力，而且面临的许多挑战来自协调活动和限制混乱的需要。

但他们都倾向于使用相同的“战术”实践来处理复杂性。我建议你阅读Joel Test的这篇介绍，以了解一些有用/必要的实践。