One million lines of code is past the point that most mortals can keep it all in their heads. That means that team members will each be carrying around incomplete mental maps of the system, which can make design discussions difficult.
To mitigate multiple, incomplete understandings, you need maps, in the form of an appropriate set of architectural diagrams. These will usually include a very high-level block diagram of the system's architecture, with more detailed lower-level diagrams for key parts, and possibly sequence diagrams for describing key interactions at an appropriate level of detail. Having such diagrams within reach help the team be "on the same page" when discussing the system.
'Dependencies between subsystems' diagrams can also point out areas of messiness (of the "Wuh? Why is that bit of the persistence framework dependent on the UI?!?" type) that need to be cleaned up. Best if if you can figure out a way to automate the generation of these diagrams. Graphviz can be your friend.
What practices do you have while developing and maintaining projects of this size?
Well, that's when you evolve from developer to architect.
With large software project, a project leader's concern shouldn't narrowed at implementation but on structure level: Properly and correctly modularise your components/libraries, well decoupling them, utilise design patterns.
For me it hasnt been the number of lines, but how modular the design is, how well encapsulated the modules are. After a certain point, if I can zoom in so to speak on a module, figure out what its design is, and write features and fix bugs, then number of lines of code doesnt matter. Arguably I havent worked on a system bigger than 1 million lines of code.
What type of Engine is that? If it's a Game Engine, it's surely modularized into Graphic, Sound, Physics, Map Handling and dozens of other modules. Every module surely contains several submodules, i.e. Graphics is split into Font-Rendering, Effects, GPU-specific parts etc.
I guess it depends. You could give a bad chef the same amount of ingredients (i.e. lots) as a good chef and the bad chef will give you something that will make you throw up whereas the good chef can make it taste good and be easily digested.
I don't think of a project in terms of number of lines but (as you have eluded to) the maintainability of the project itself. As long as the project is modularized and well refactored it might not be too bad.
So to answer your question, practices that I use to maintain a large code base would be the same one to maintain any size code base - I would look at integrating an automated build with a high code coverage (preferably with system level tests), include tools to help you have readable (e.g. checkstyle) and no duplicated code (e.g. simian) and things such as that.
If the project continues to grow and you reach a large number of lines and you develop the code base properly, I guess it can only mean that your clients are happy and want more features.
但他们都倾向于使用相同的“战术”实践来处理复杂性。我建议您阅读 Joel 测试 的介绍，了解一些有用的/所需的做法。
What practices do you have while developing and maintaining projects of this size?
There are many school of thoughts for managing large software projects, and obviously it largely depends on the type of project:
Funded software development (that might cover some Open Source projects to which corporation are contributing, think Eclipse),
"Hobbyist" software development that's been wildly successful (think Linux).
Funded software development will typically tend to use formal process from the beginning, where "hobbyist" project tend to adopt only the required practices to address paint points as they appear.
As it has been pointed out by others a project of that size is necessarily a team effort, and a lot of the challenges faced come from the need to coordinate activities and limit chaos.
But they will all tend to use the same "tactical" practices to handle the complexity. I suggest you read this introduction to the Joel Test to get a sense of some useful/required practices.
发布评论
评论（7）
一百万行代码已经超出了大多数人能够记住的程度。这意味着团队成员每个人都将携带不完整的系统思维导图，这会使设计讨论变得困难。
为了减轻多重、不完整的理解，您需要采用一组适当的架构图形式的地图。这些通常包括系统架构的非常高级的框图，以及关键部分的更详细的较低级图，以及可能的用于以适当的细节级别描述关键交互的序列图。拥有这样的图表可以帮助团队在讨论系统时“达成共识”。
“子系统之间的依赖关系”图还可以指出需要清理的混乱区域（“呃？为什么持久性框架的那部分依赖于 UI？！？”类型）。如果您能找到一种自动生成这些图表的方法，那就最好了。 Graphviz 可以成为你的朋友。
One million lines of code is past the point that most mortals can keep it all in their heads. That means that team members will each be carrying around incomplete mental maps of the system, which can make design discussions difficult.
To mitigate multiple, incomplete understandings, you need maps, in the form of an appropriate set of architectural diagrams. These will usually include a very high-level block diagram of the system's architecture, with more detailed lower-level diagrams for key parts, and possibly sequence diagrams for describing key interactions at an appropriate level of detail. Having such diagrams within reach help the team be "on the same page" when discussing the system.
'Dependencies between subsystems' diagrams can also point out areas of messiness (of the "Wuh? Why is that bit of the persistence framework dependent on the UI?!?" type) that need to be cleaned up. Best if if you can figure out a way to automate the generation of these diagrams. Graphviz can be your friend.
分而治之，因此不会有如此规模的整体项目。
Divide and conquer, thus not having a monolithic project of this size.
好吧，那就是你从开发人员转变为架构师的时候。
对于大型软件项目，项目负责人的关注点不应缩小在实现上，而应缩小在结构级别上：正确和正确地模块化您的组件/库，很好地解耦它们，利用设计模式。
Well, that's when you evolve from developer to architect.
With large software project, a project leader's concern shouldn't narrowed at implementation but on structure level: Properly and correctly modularise your components/libraries, well decoupling them, utilise design patterns.
对我来说，重要的不是行数，而是设计的模块化程度，模块的封装程度。在某一点之后，如果我可以放大一个模块，弄清楚它的设计是什么，并编写功能并修复错误，那么代码行数并不重要。可以说我还没有开发过超过 100 万行代码的系统。
For me it hasnt been the number of lines, but how modular the design is, how well encapsulated the modules are. After a certain point, if I can zoom in so to speak on a module, figure out what its design is, and write features and fix bugs, then number of lines of code doesnt matter. Arguably I havent worked on a system bigger than 1 million lines of code.
那是什么类型的发动机？如果它是一个游戏引擎，它肯定会模块化为图形、声音、物理、地图处理和数十个其他模块。每个模块肯定包含多个子模块，即图形分为字体渲染、效果、GPU 特定部分等。
What type of Engine is that? If it's a Game Engine, it's surely modularized into Graphic, Sound, Physics, Map Handling and dozens of other modules. Every module surely contains several submodules, i.e. Graphics is split into Font-Rendering, Effects, GPU-specific parts etc.
我想这要看情况。你可以给一个坏厨师提供与一个好厨师相同数量（即很多）的食材，坏厨师会给你一些会让你呕吐的东西，而好厨师可以让它味道好并且容易消化。
我不考虑项目的行数，而是考虑项目本身的可维护性（正如您所回避的那样）。只要项目是模块化的并且重构得很好，它可能不会太糟糕。
因此，为了回答您的问题，我用于维护大型代码库的做法与维护任何规模代码库的做法相同 - 我会考虑将自动化构建与高代码覆盖率（最好是系统级测试）集成，包括帮助您获得可读（例如 checkstyle）且无重复代码（例如 simian）之类的工具。
如果项目继续增长并且您达到了大量的行数并且正确地开发了代码库，我想这只能意味着您的客户很高兴并且想要更多功能。
I guess it depends. You could give a bad chef the same amount of ingredients (i.e. lots) as a good chef and the bad chef will give you something that will make you throw up whereas the good chef can make it taste good and be easily digested.
I don't think of a project in terms of number of lines but (as you have eluded to) the maintainability of the project itself. As long as the project is modularized and well refactored it might not be too bad.
So to answer your question, practices that I use to maintain a large code base would be the same one to maintain any size code base - I would look at integrating an automated build with a high code coverage (preferably with system level tests), include tools to help you have readable (e.g. checkstyle) and no duplicated code (e.g. simian) and things such as that.
If the project continues to grow and you reach a large number of lines and you develop the code base properly, I guess it can only mean that your clients are happy and want more features.
管理大型软件项目有很多思想流派，显然这在很大程度上取决于项目的类型：
受资助的软件开发通常倾向于从一开始就使用正式流程，其中“业余爱好者”项目倾向于仅采用所需的实践来解决出现的问题。
正如其他人指出的那样，如此规模的项目必然需要团队的努力，并且面临的许多挑战来自于协调活动和限制混乱的需要。
但他们都倾向于使用相同的“战术”实践来处理复杂性。我建议您阅读 Joel 测试 的介绍，了解一些有用的/所需的做法。
There are many school of thoughts for managing large software projects, and obviously it largely depends on the type of project:
Funded software development will typically tend to use formal process from the beginning, where "hobbyist" project tend to adopt only the required practices to address paint points as they appear.
As it has been pointed out by others a project of that size is necessarily a team effort, and a lot of the challenges faced come from the need to coordinate activities and limit chaos.
But they will all tend to use the same "tactical" practices to handle the complexity. I suggest you read this introduction to the Joel Test to get a sense of some useful/required practices.