我正在听一个小组讨论，其中有人提到他们的“引擎”不是 1.3，但现在是 170 万行代码。这让我害怕。我无法想象行数、模块的数量等等。我一直觉得 C++ 处理模块的能力不如其他语言。我觉得大型项目更难管理，更喜欢合理地减少代码行数。当我达到 10k 行时，我感到不舒服。我无法想象 20k、50k、500k 或 100 万的感觉如何。
在开发和维护这种规模的项目时，您有哪些实践？
user34537
问问题
670 次
7 回答
7
一百万行代码已经超过了大多数人可以记住的程度。这意味着每个团队成员都将携带系统的不完整心理地图，这可能会使设计讨论变得困难。
为了减轻多重、不完整的理解，您需要以一组适当的架构图形式的地图。这些通常包括系统架构的非常高级的框图，关键部分的更详细的低级图表，以及用于以适当的详细程度描述关键交互的序列图。在讨论系统时，让这样的图表触手可及有助于团队“在同一页面上”。
“子系统之间的依赖关系”图还可以指出需要清理的混乱区域（“呃？为什么持久性框架的那一点依赖于 UI？！？”类型）。如果你能找到一种方法来自动生成这些图表，那就最好不过了。Graphviz 可以成为你的朋友。
于 2010-01-08T06:51:49.273 回答
6
在开发和维护这种规模的项目时，您有哪些实践？
分而治之，因此没有这种规模的单体项目。
于 2010-01-08T05:34:25.730 回答
3
在开发和维护这种规模的项目时，您有哪些实践？
嗯，这就是你从开发人员演变为架构师的时候。
对于大型软件项目，项目负责人的关注点不应该在实施上而是在结构层面上缩小：正确地模块化你的组件/库，很好地解耦它们，利用设计模式。
于 2010-01-08T05:36:47.697 回答
2
对我来说，这不是行数，而是设计的模块化程度，模块的封装程度。在某一点之后，如果我可以放大一个模块，弄清楚它的设计是什么，编写功能并修复错误，那么代码行数就无关紧要了。可以说我没有在超过 100 万行代码的系统上工作过。
于 2010-01-08T05:35:24.313 回答
0
那是什么类型的引擎？如果它是一个游戏引擎，它肯定会模块化成图形、声音、物理、地图处理和其他几十个模块。每个模块肯定包含几个子模块，即图形分为字体渲染、效果、GPU 特定部分等。
于 2010-01-08T05:37:43.623 回答
0
我想这取决于。您可以给坏厨师提供与好厨师相同数量的食材（即很多），而坏厨师会给您一些让您呕吐的东西，而好厨师可以使其味道好且易于消化。
我不考虑项目的行数，而是考虑项目本身的可维护性（正如你所逃避的）。只要项目是模块化的并且重构得很好，它可能不会太糟糕。
因此，为了回答您的问题，我用来维护大型代码库的做法与维护任何大小的代码库的做法相同 - 我会考虑将自动化构建与高代码覆盖率（最好是系统级测试）集成，包括帮助您具有可读性（例如 checkstyle）并且没有重复代码（例如 simian）和诸如此类的东西的工具。
如果项目继续增长并且您达到大量行并且您正确开发代码库，我想这只能意味着您的客户很高兴并且想要更多功能。
于 2010-01-08T05:38:34.340 回答
0
在开发和维护这种规模的项目时，您有哪些实践？
管理大型软件项目有很多思想流派，显然这在很大程度上取决于项目的类型：
- 资助的软件开发（可能涵盖一些公司正在贡献的开源项目，想想 Eclipse），
- 非常成功的“爱好者”软件开发（想想 Linux）。
受资助的软件开发通常会从一开始就倾向于使用正式的流程，其中“爱好者”项目倾向于仅采用所需的实践来解决出现的油漆点。
正如其他人所指出的那样，如此规模的项目必然是团队的努力，面临的许多挑战来自协调活动和限制混乱的需要。
但他们都倾向于使用相同的“战术”实践来处理复杂性。我建议您阅读Joel 测试的介绍，以了解一些有用/必需的实践。
于 2010-01-08T07:09:12.220 回答