blocks|key|80733|text|非类型化和过程化的语言在大型项目中被分解了。它一直是这样的，这就是为什么OO被创造出来，像解耦和封装这样的东西被认为是很好的设计方法。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|80734|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Untyped and procedural languages break down in large projects. It's always been this way, this is why OO was made and things like decoupling and encapsulation are considered good design methodologies.

blocks|key|81840|text|当然，首先使用面向对象编程和继承。接下来，我会使用一些框架，比如代码启动器来开始，添加模块来布局(这样你就会有一致的网站布局)，或者其他一些框架，重点是不要在常见的事情上花费太多的时间。不幸的是，CI的迁移并不是很好，但它们是存在的，所以沿着这些路线的一些东西将对处理db很有用。有了这些，你可以再次拥有你的生产力，因为你不会把时间花在小事上。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|81841|更大的项目有多个方面，并且这些方面存在的越多，你需要花费更多的时间来考虑它们。|81842|希望这能有所帮助。|81843|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Sure, first use oo programming and inheritance. Next, I would use framework like code igniter for start, add module for layout (so you would have consistent site layout) and maybe few others, point is not to spend too much time on common things. Unfortunatelly migrations for CI are not great, yet they exist, so something along those lines would be useful to deal with db. 
With those, you can have your productivity again as you will not spend time on small things. 

Thing with bigger projects is that they have multiple aspects and the more those exist, the more time you need to spend taking them into account.

Hope this helps.

blocks|key|4254182|text|永远不要以在记事本中编辑代码为荣！IDE可以节省您的时间，提高您的效率。当项目变得很大时，你应该注意项目管理，并坚持一个有效的“过程模式”，如RUP+(Rational+Unified+Process)，EUP或OOSP。你的SVN是供应链管理的一部分。当然，对于文件管理问题，在Pattern.As中定义的活动要多得多，您可以将它们划分为不同的包，并将它们保存在不同的位置。如果你对“软件工程”没有任何概念，你可以参考一些Scott+W+Ambler或其他人写的关于SE(软件工程)的书。记住，软件远不止是代码！|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|4254183|一个优秀的开发人员知道，除了编程之外，还有更多的事情要做。一个伟大的开发者知道开发比开发更重要。+By+Scott+W+Ambler|4254184|entityMap^0|10|23|0|0|1C|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|M|8|@$9|N|A|O|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|P|8|@]|D|@]|E|$]]]|I|$]]

Never be proud of editing code in a notepad! IDE saves your time and increases your efficiency. When project becomes large, you should take care of the project management and stick to a efficient "Process Pattern", such as RUP (Rational Unified Process), EUP or OOSP. Your SVN is a part of SCM. Of course, there are far more activities defined in a Pattern.As for the file management problem, you can divided them into different packages and save them in different places. If you don't have any idea of "Software Engineering", You can refer to some books written by Scott W Ambler or others about SE(Software Engineering). Remember, Software is far more than CODE!

A good developer knows that there is more to development than programming.
A great developer knows that there is more to development than development. By Scott W Ambler

blocks|key|4254206|text|绘制和/或写出它。如果你说“一切都在你的脑海中”，那么从编码中抽出一些时间来记录你的工作。这可以包括解释你为什么要做某事的段落。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4254207|图表和其他视觉效果也可以帮助你保持条理清晰。|4254208|我发现一些程序员忽略了项目中的非技术因素。对于没有团队结构来指导他们的开发人员来说，这一点尤其正确。您的工作不仅仅是代码，您应该查看流程的各个方面。|4254209|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Draw and/or write it out. If you say it's 'all in your head', then take some time away from the coding and document your work. This can include paragraphs explaining why you did something.

Diagrams and other visuals will also help you keep it organized. 

I've found some programmers ignore the non-technical factors in projects. This is especially true for lone developers who don't have the structure of a group to guide them. Your work is more than just code and you should look at all aspects of your process.

blocks|key|1036810|text|测试驱动开发可能对您有用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1036811|首先构建您的测试，然后编写代码以通过这些测试。|1036812|当您添加/更改任何代码时，可以运行一个回归测试套件，以确保您没有破坏某些东西。根据我的经验，这可以节省大量时间，尤其是在应用程序的复杂性和大小不断增长的情况下。|1036813|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Test Driven Development might be useful to you.

Build your tests first, then write the code to pass those tests.

When you add/change any code, have a regression test suite you can run to make sure you haven't broken something. In my experience, this saves loads of time, particularly as an application grows in complexity and size.

blocks|key|80829|text|大型代码库的生产力更多地取决于您编写的代码，而不是工具。花时间提高你的代码的质量，无论是新的还是现有的。是的，它会在短期内放慢你的速度，但它可以让你随着时间的推移保持你的速度。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|80830|无论您的工具或语言如何，这一点都适用。世界上最好的工具也不会帮助那些想把事情搞乱的人。首先，我会在脑海中记住一些简单的想法：|80831|80832|代码质量是对未来的投资，你的直觉告诉你代码是糟糕的、复杂的、错误的、丑陋的……很可能是，修复它。|unordered-list-item|80833|停止编写糟糕的代码，现在，而不是明天。|80834|80835|有关如何设计优秀代码的更多深入信息，我建议浏览一下here。|offset|length|80836|entityMap|0|LINK|mutability|MUTABLE|url|http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod^0|0|0|0|0|0|0|P|4|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|Z|8|@]|9|@]|A|$]]|$1|H|3|I|5|G|7|10|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|11|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|12|8|@]|9|@$M|13|N|14|1|15]]|A|$]]|$1|O|3|-4|5|6|7|16|8|@]|9|@]|A|$]]]|P|$Q|$5|R|S|T|A|$U|V]]]]

Productivity on large code bases is less about tools and more about the code you write. Spend time improving the quality of your code, both new and existing. Yes it slows you down in the short term but it allows you to maintain your pace as time goes on.

This applies regardless of your tools or language. The best tools in the world will not help someone who is out to make a mess. To start with I'd keep some simple ideas in mind:

<ul>
<li>Code quality is an investment in future productivity.</li>
<li>If your gut tells you code is bad, complex, wrong, ugly... it probably is, fix it.</li>
<li>Stop writing bad code, now, not tomorrow.</li>
</ul>

For much more in depth information on how to design great code I suggest having a browse around <a href="http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod" rel="nofollow noreferrer">here</a>.

blocks|key|81976|text|我曾经在一个项目中工作，这个项目大约有一百万行代码(C#、C%2B%2B)，而且还在不断增长。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|81977|1)为了管理这样的代码库，svn归档的文件夹结构被创建为模仿我们产品的各个架构层。这样就更容易在归档文件中找到我们的方式了。|81978|2)我们也有自己的定制构建工具。当你有一个庞大的代码库时，当你想要测试一个小功能时，构建所有的代码可能是不可行的。我们的自定义构建工具有很多选项，可以在任何粒度构建归档文件。|81979|3)通常我观察到的是，如果你的通用功能/帮助器是正确的，那么在它之上构建新的东西就会变得更容易，同时也避免了代码膨胀。|81980|4)如果在你的项目中工作的开发人员数量较多，请设置一个wiki。如果处理得当，Wiki文档是毫不费力的，可以搜索，而且很有帮助。|81981|这就是我现在能想到的一切。希望这能有所帮助|81982|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Q|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

I used to work on a project that had roughly a million lines of code (C#,C++) and it is still growing.

1) To manage such a code base, the folder structure of the svn archive was created in such a way that it would mimic various architectural layers of our product. This way it became easier to find our way through the archive.

2) Also we had our own custom build tool. When you have a huge code base, it might not be feasible to build everything anytime you want to test a small feature. Our custom build tool had lots of options, that could build the archive at any granularity.

3) Usually what I have observed is if you get the generic functionality/helpers right, building new things on top of it becomes easier and also avoids code bloat.

4)Set up a wiki, if the number of developers working on your project are more. Wiki documentation is effortless, search able and helpful if done right.

That's all I can think of right now. Hope this helps

blocks|key|1381303|text|使用PHP+MVC框架将极大地减少您必须跟踪的代码量。通过使用框架，它将帮助你在逻辑上组织你的文件。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1381304|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Using a PHP MVC framework would greatly reduce the amount of code you have to keep track of. It will take care of many of the things you probably had to write yourself like session, database layer, etc. By using a framework, it will help you organize your files logically.

blocks|key|4254484|text|我发现测试驱动开发(TDD)+/行为驱动开发(BDD)可以帮助我在事情变大时保持有序。即使您只编写单元测试，抛开功能、集成和其他测试不谈，这本身就可以提供巨大的帮助。当你的代码库变成了Doom的笨拙、摇摇欲坠的沼泽时，你的测试将使它或多或少地沿着正确的方向摇摇欲坠，并防止它被岩石绊倒，脸朝下掉在泥地里，或者因为太重而无法站起来而被淹没。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4254485|如果您编写了足够多的测试，并且它们经过深思熟虑，那么它们就可以完成测试，这样您就可以进行更改，并立即知道更改是否会破坏某些东西。在没有测试的情况下，在特定的时间点之后，你几乎不能改变任何东西。|4254486|我不太了解PHP场景，但是似乎有一些PHP的测试框架，包括一个叫做PHPUnit的框架。|offset|length|4254487|entityMap|0|LINK|mutability|MUTABLE|url|http://www.phpunit.de/^0|0|0|X|7|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@$F|S|G|T|1|U]]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

I have found that test-driven development (TDD) / behavior driven development (BDD) helps me keep things in order as they get larger. Even if you just write unit tests, leaving aside functional, integration, and other tests, that alone can be a huge help. As your code base turns into a lumbering, shambling Swamp Thing of Doom, your tests will keep it shambling in more or less the right direction and will prevent it from tripping over a rock, falling face down in the mud, and drowning because it's too heavy to get up.

If you write enough tests and they're well thought out they can make it so that you can make changes and know right away if the change broke something. Without tests, after a certain point you kind of can't change anything.

I don't know the PHP scene too well but it appears that there are testing frameworks for PHP, including one called <a href="http://www.phpunit.de/" rel="nofollow noreferrer">PHPUnit</a>.

blocks|key|1383552|text|围绕着OOP将拯救世界的神话是怎么回事？如果这是真的，为什么Linux/Kernel的家伙们仍然每周都在推动新版本呢？换句话说，所有的ASM/C程序员都注定了"Hello+World“的复杂性吗？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1383553|不知道你到底想要什么。我的意思是在问题发生之前和发生时进行工作：|1383554|1383555|如果你有很多文件和LOC，只需减少和重组它们即可。例如，为某些任务构建或使用坚如磐石的框架(PDO而不是mysql())。换句话说，不要重复你自己。简短，朗朗上口，类似的函数名称:+get_user_ID()，get_task_ID()，db_query()....|unordered-list-item|1383556|Is在组中通信有问题吗？尝试维基，尝试内部即时消息，尝试使用更多评论，询问群组他们不喜欢什么，希望得到改进。这完全取决于项目。|1383557|如果你在一个团队中工作，不要到处走动。在你的部分上工作，并改进它们。这节省了你进入其他程序员思维模式所需的时间。一次只有一个变化。不要打开200个文件和编辑完全不相关的things.|1383558|Automate，如果可能的话，加速一切:部署，版本控制，文档，测试。|1383559|大项目都是大项目，这些项目总是很难完全理解。KISS很好，但根据我的经验，它有时会有助于将事情分解为通过XML、语言特定接口等进行通信的独立工作组件。简而言之:从大项目中做很多小项目。由于"myname.todo.txt".|1383560|Fast部署是强制性的，|1383561|我有一个个人的待办事项/记住列表！例如，安装本地lamp/xampp并直接查看您的更改。|1383562|1383563|entityMap^0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|Z|8|@]|9|@]|A|$]]|$1|H|3|I|5|G|7|10|8|@]|9|@]|A|$]]|$1|J|3|K|5|G|7|11|8|@]|9|@]|A|$]]|$1|L|3|M|5|G|7|12|8|@]|9|@]|A|$]]|$1|N|3|O|5|G|7|13|8|@]|9|@]|A|$]]|$1|P|3|Q|5|G|7|14|8|@]|9|@]|A|$]]|$1|R|3|S|5|G|7|15|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|16|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|17|8|@]|9|@]|A|$]]]|V|$]]

What about this myth floating around that OOP will save the day? If that's true, how come the Linux/Kernel guys are still pushing new versions on a weekly basis? In other words are all ASM/C programmers doomed to "Hello World" complexity?

Not sure what exactly you are asking for. I mean work on the problems before and when they occur: 

<ul>
<li>If you have to many files and LOCs just reduce and reorganize them. For example by building or using rock solid frameworks for certain tasks (PDO instead of mysql()). In other words, don't repeat yourself. Short, catchy, similar function names: get_user_ID(), get_task_ID(), db_query()....</li>
<li>Is communication in the group a problem? Try wikis, try internal IM, try using more comments, ask the group what they dislike and want to be improved. It totally depends on the project.</li>
<li>If you work in a group, don't be all over the place. Work on your parts and improve them. That saves time you need to get into the others programmers mindset. One change at a time. Don't open up 200 files and edit totally unrelated things.</li>
<li>Automate and speedup everything, if possible: deployment, versioning, documentation, tests.</li>
<li>Big projects are big projects and these are always hard to fully understand. KISS is good, but in my experience it sometimes helps to just break down the thing to independently working components communicating via XML, language specific interfaces etc... In short: Make a lot of small projects out of the big one.</li>
<li>I keep a personal todo/remember list as "myname.todo.txt".</li>
<li>Fast deployment is mandatory! For example install a local lamp/xampp and directly view your changes.</li>
</ul>

blocks|key|82059|text|在我看来，你有一个巨大的PHP项目。这是可以做到的，但你真的需要组织起来。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|82060|尽可能地将其分解为独立的部分，每个部分只有一个小接口。|82061|尽可能多地“完成”。然后将“完成”的代码视为API，这样您就不必再查看它了。一周4.5天，假设是别人写的，而你只知道接口。|82062|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

You have a huge project for PHP, in my opinion. It can be done, but you really need to organize.

Break it down into independent pieces as much as possible, each with just a small interface.

"Finish" as much as you can. Then treat that "finished" code as an API, so you don't have to look at it anymore. 4.5 days of the week, assume that someone else wrote it and that you only know the interface.

blocks|key|4254590|text|养成定期研究你的代码并寻找消除重复的方法的习惯(例如，应用‘t+Repeat++or+DRY原则)，并毫不留情地重构这些重复。越多地将公共代码片段放入可重用的方法和类中，就越容易编写新代码，并且在问题上获得的影响也越大。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|4254591|使用一个好的集成开发环境将帮助您找到共性并应用重构。|4254592|另外，还要寻找能够自动化软件各个方面的开源框架和工具。使用它们是DRY原则的大量应用。|4254593|entityMap^0|T|A|0|6|6|0|L|5|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@$9|P|A|Q|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|R|8|@$9|S|A|T|B|C]]|D|@]|E|$]]|$1|J|3|-4|5|6|7|U|8|@]|D|@]|E|$]]]|K|$]]

Get in the habit of regularly studying your code and looking for ways to eliminate repetition (ie, apply the Don't Repeat Yourself or DRY principle), and be ruthless in refactoring that repetition away. The more you push common code snippets into reusable methods and classes, the easier it is to write new code, and the more leverage you gain on the problem. 

Using a good IDE will help you find commonalities and apply refactorings.

Also look for open source frameworks and tools that automate aspects of your software. Using them is a massive application of the DRY principle.

blocks|key|1383625|text|每次迭代后的|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1383626|重构-维护干净的代码库|ordered-list-item|1383627|打破依赖关系-帮助代码库易于理解|1383628|具有自动化的单元测试和测试工具-减少每次迭代后新功能的周转时间|1383629|更新文档和可追溯性-帮助理解代码。|1383630|<+code+>G29|1383631|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|Q|8|@]|9|@]|A|$]]|$1|G|3|H|5|D|7|R|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|S|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|T|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|U|8|@]|9|@]|A|$]]]|N|$]]

<ol>
<li>Refactor after every iteration - maintains clean code base </li>
<li>Breaking Dependencies - helps the codebase to be simple to understand </li>
<li>Have automated unit tests and test harness - reduces the turnaround time for a new feature </li>
<li>Update documentation and tracebility after every iteration - helps to understand the code.</li>
</ol>

blocks|key|1381429|text|PHP中的大项目？不只是银弹，没有铅弹，甚至连泥弹都很稀缺。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1381430|不同的语言！|1381431|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Big project in PHP? Not just silver bullets, there are no lead bullets and even clay bullets are scarce.

Different language!

blocks|key|82151|text|我的第一个想法是，你需要写下东西。你关于“一切都在我脑海里”的评论让我担心|type|unstyled|depth|inlineStyleRanges|entityRanges|data|82152|82153|最终你会忘记一些非常重要的事情，浪费时间去计算或重建一些东西，因为你不能remember.|ordered-list-item|82154|Future项目中的程序员会因为你没有记录任何东西而恨你。|82155|82156|我发现，即使我是唯一的用户，维基在组织我的想法方面也是非常有帮助的。编辑过程简单而快速，这让我可以将我大脑中的内容直接转储到一个可搜索的数字媒体中。|82157|选择哪种wiki并不重要，只要花点时间真正学习语法就可以了，这样你就不会一直把注意力转向格式化了。|82158|那就坐下来，把甩了。|offset|length|style|BOLD|82159|一旦你在页面上有了东西，你就可以开始重新组织你的想法，当它就在你面前时，更容易从高层次上看到整个系统架构。|82160|我还发现了许多聪明和有趣的方法来修复我的架构，只需在我面前的一个完全不同的媒介。|82161|entityMap^0|0|0|0|0|0|0|0|6|1|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|10|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|11|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|12|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|13|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|14|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|15|8|@$O|16|P|17|Q|R]]|9|@]|A|$]]|$1|S|3|T|5|6|7|18|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|19|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]]|X|$]]

My first thought is that you need to write stuff down. Your comment about "it's all in my head" worries me that

<ol>
<li>Eventually you're going to forget something seriously important and waste time figuring our or rebuilding something because you can't remember.</li>
<li>Future programmers on the project are going to hate you for not documenting anything.</li>
</ol>

I find a wiki, even if I'm the only user, is phenomenally helpful in organizing my thoughts. The editing process is easy and quick, which allows me to literally core dump the contents of my brain into a searchable, digital medium.

It doesn't matter which wiki you choose, just take some time to really learn the syntax so it you're not constantly switching your attention to formatting.

Then just sit down and dump.

Once you've got stuff on the page, you can start reorganizing your thoughts, and it's easier to see the entire system architecture from a high level when it's right there in front of you.

I've also found plenty of clever and interesting ways to fix my architecture by just having it all in front of me in a completely different medium.

blocks|key|1037255|text|正如Steve+McConnel所说，编程中的主要挑战是管理复杂性。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1037256|有几种方法可以对其进行管理：|1037257|1037258|使用正确的工具(好的IDE、VCS等)，您可以管理更高的复杂性-但随着复杂性的增加，您迟早将无法管理它。|ordered-list-item|1037259|使用正确的技术(OOP、测试驱动程序等)您可以降低复杂性-但它很快就会增加正确的方法(重构、单元测试等)。在很多规则中，你可以降低复杂性增加的速度，但这会增加nevertheless.|1037260|Using清晰的界面，可能会允许将项目拆分给更多的人，每个人都必须处理更低的复杂性-但随着团队的发展，团队沟通的复杂性将会越来越高。|1037261|1037262|在我个人看来，前两点(工具和技术)确实很好，但不是真正改变的东西。例如，我的团队中有一些同事使用旧的编辑器，他们的工作效率几乎与使用Eclipse的同事一样高。|1037263|另一方面，另外两点将更有帮助:纪律、良好的设计和重构将有助于将复杂性保持在尽可能低的水平，而良好的团队合作可以处理更大的项目，而这些项目本身就太复杂了。|1037264|然而，正如您已经指出的，没有什么灵丹妙药。最终，任何成功的软件的复杂性都会增长到这样一个程度，即维护成本可能变得如此昂贵，以至于需要全新的一代。|1037265|这就是软件的生活:-)|1037266|entityMap^0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|Z|8|@]|9|@]|A|$]]|$1|H|3|I|5|G|7|10|8|@]|9|@]|A|$]]|$1|J|3|K|5|G|7|11|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|12|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|13|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|14|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|15|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|16|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|17|8|@]|9|@]|A|$]]]|V|$]]

As Steve McConnel says, the main challenge in programming is managing complexity.

You have several ways to manage it:

<ol>
<li>Using the right tools (good IDEs, VCS, etc) , you can manage an higher amount of complexity - but as complexity increases, sooner or later you will not be able to manage it.</li>
<li>Using the right techniques (OOP, TDD, etc) you can reduce complexity - but it will soon increase steadily.</li>
<li>Using the right approaches (refactoring, unit testing, etc.) and a lot of discipline you can reduce the pace at which complexity increases - but it will increase nevertheless.</li>
<li>Using clear interfaces may allow splitting the project among more people, each of which will have to handle a lower complexity - but as the team grows, the complexity of team communications will increase ever more.</li>
</ol>

In my personal opinion, the first two points (tools and techniques) are indeed good, but not something that really changes. For instance, I have colleagues in my team that use old editors, and are almost as productive as colleagues using Eclipse. 
The other two points, on the other hand, will help much more: discipline, good designs, and refactoring will help maintaining complexity as low as possible, and good team working allows for tackling bigger projects that alone would be really too complex. 

However, as you already pointed out, there is no silver bullet. In the end, the complexity of any successful software grows to a point where its maintenance may become so expensive to require a complete new generation. 
And that's life in software :-)

blocks|key|82193|text|别再假装你能把这一切都记住了。在某种程度上(看起来你已经达到了)，这再也不可能了。如何处理一个太大而无法记忆的项目？嗯，就像你处理另一个人写的项目，或者你写的是由别人维护的项目一样。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|82194|最重要的一点是:写出好的代码。对类、方法、变量等使用一致的、有意义的名称。方法)，这些方法完全按照名称所说的那样做，不多也不少。没有棘手的捷径，意想不到的副作用，定时炸弹，惊喜。你必须能够自信地使用一个函数，而不需要阅读它的实现来检查它做了什么以及如何做。|82195|组织你的代码。将GUI代码与业务逻辑代码分开。将它们放在单独的文件夹中。如果文件同时包含两者，则对其进行重构。如果您已经生成了代码，请将其保存在单独的文件夹中(这样您就永远不会想要修改它)。|82196|使用版本控制系统。(不能说得太多)|82197|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Stop pretending that you can keep it all in your head. At some point (looks like you have reached it), it's simply no longer possible.
How to deal with a project too large to memorize? Well, the same way you handle projects that were written by another person, or that you write to be maintained by someone else.

The single most important item: Write good code. Use consistent, meaningful names for classes, methods, variables etc. Write functions (resp. methods) that do exactly what the name says, no more, no less. No tricky shortcuts, unexpected side effects, timebombs, surprises. You must be able to use a function with confidence, without reading its implementation to check what it does and how.

Organize your code. Seperate GUI code from business logic code. Keep them in separate folders. If a file contains both, refactor it. If you have generated code, keep that in a separate folder (so you are never tempted to modify it).

Use a Revision Control System. (Can't be said too often)

blocks|key|1037400|text|在这里走一段路，但将项目分解成较小的项目/API/模块/包/程序集(你想叫它们什么)应该是下一个合乎逻辑的步骤。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1037401|1037402|开始很小，只有几个文件，小编辑器，命令行构建，一切都很好……|unordered-list-item|1037403|变得更大，版本变得更棘手，转移到了SVN和集成开发环境……BIIIG在productivity|1037404|Then项目中的推动作用变得更大，不知所措的感觉又回来了……|1037405|1037406|人类的大脑只能同时处理这么多的事情，我们的工作记忆也只能处理这么多的事情。在较高的抽象级别后面隐藏较小的细节将使您能够忘记这些文件，直到出现问题为止。如果发生这种情况，你只需要打开那个特定的引擎盖就可以把它修好。使用不同级别的抽象，你的项目会突然变得小得多，其中只有一小部分单元是有意义的，而其余的只是为了让它们工作。OOP非常擅长隐藏实现细节，同时暴露更高级别的功能主义者。也就是说，除了OOP之外，还有其他范例可供选择。|1037407|所以在这一点上我给你的建议|1037408|1037409|将您的项目分解为较小的块，每个块都有一个接口，使您可以通过一个单点访问其余部分。|1037410|使用单元测试和其他测试技术以及良好的测试框架来单独测试每个块。这将使您能够测试接口，并查看它是否是useful.|1037411|Never访问接口背后的东西，如果您觉得需要，更改接口，测试，然后使用接口。这是最重要的部分，忽略这一点将使您回到现在的问题(耦合太多)，因此尽可能减少块之间的交互点，从而减少接口。|1037412|1037413|这将允许您大幅减少您必须记住的关于项目的事情的数量，并将很好地扩展到下一个数量级。|1037414|然后，您的下一步将是更深入地研究OOP，并学习架构和设计模式。它们将帮助您进一步减少系统的域。|1037415|有用的花边新闻|1037416|1037417|http://www.simpletest.org/|offset|length|1037418|http://www.phpunit.de/|1037419|http://laughingmeme.org/2003/08/05/a-few-tips-for-writing-useful-libraries-in-php/|1037420|1037421|entityMap|0|LINK|mutability|MUTABLE|url|1|2^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|Q|0|0|0|M|1|0|0|2A|2|0|0^^$0|@$1|2|3|4|5|6|7|1L|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|1M|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|1N|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|1O|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|1P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|1R|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|1S|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|1T|8|@]|9|@]|A|$]]|$1|P|3|Q|5|E|7|1U|8|@]|9|@]|A|$]]|$1|R|3|S|5|E|7|1V|8|@]|9|@]|A|$]]|$1|T|3|U|5|E|7|1W|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|1X|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|10|3|11|5|6|7|20|8|@]|9|@]|A|$]]|$1|12|3|-4|5|6|7|21|8|@]|9|@]|A|$]]|$1|13|3|14|5|E|7|22|8|@]|9|@$15|23|16|24|1|25]]|A|$]]|$1|17|3|18|5|E|7|26|8|@]|9|@$15|27|16|28|1|29]]|A|$]]|$1|19|3|1A|5|E|7|2A|8|@]|9|@$15|2B|16|2C|1|2D]]|A|$]]|$1|1B|3|-4|5|6|7|2E|8|@]|9|@]|A|$]]|$1|1C|3|-4|5|6|7|2F|8|@]|9|@]|A|$]]]|1D|$1E|$5|1F|1G|1H|A|$1I|14]]|1J|$5|1F|1G|1H|A|$1I|18]]|1K|$5|1F|1G|1H|A|$1I|1A]]]]

Going on a limb here but breaking the project in smaller projects/API/modules/packages/assemblies (call them what ever you want) should be the next logical step here.

<ul>
<li>Started small, few files, small editor, command line builds, all was good...</li>
<li>Got bigger, versions got trickier, moved to SVN and IDE... BIIIG boost in productivity</li>
<li>Then project got even bigger and the feeling of being overwhelmed creeps back again...</li>
</ul>

The human brain can only process so many things at the same time, there is just so much our working memory can handle. Hiding smaller details behind a higher abstraction level will enable you to forget about these files until there is something wrong under the hood. If that ever happens you only need to open that particular hood to fix it there. Use different level of abstractions and your projects will become suddenly much smaller where only a handful of units will be meaningful while the rest is just to make them work. OOP is very good at hiding implementation details while exposing higher level functionalists. This being said there are other paradigms than OOP that you can choose from.

So my advice to you at this point

<ul>
<li>Break down your projects in smaller chunks each with an interface that will give you a single point of access to the rest.</li>
<li>Use Unit testing and other testing techniques with a good testing framework to test each chunk individually. This will enable you to test the interface and see if it is useful.</li>
<li>Never access the stuff behind the interface, if you feel the need, change the interface, the tests and then use the interface. This is the most important part, ignoring this will get you back in the problem you have now (too much coupling), therefore reduce as much as possible the points of interactions between the chunks, hence the interfaces.</li>
</ul>

This will allow you to reduce dramatically the number of things you have to remember about your project and will scale well to the next order of magnitude.

Then your next step will be at looking at OOP more in depth and learn about architecture and design patterns. They will help you reducing even more the domain of your system.

usefull tidbits

<ul>
<li><a href="http://www.simpletest.org/" rel="nofollow noreferrer">http://www.simpletest.org/</a></li>
<li><a href="http://www.phpunit.de/" rel="nofollow noreferrer">http://www.phpunit.de/</a></li>
<li><a href="http://laughingmeme.org/2003/08/05/a-few-tips-for-writing-useful-libraries-in-php/" rel="nofollow noreferrer">http://laughingmeme.org/2003/08/05/a-few-tips-for-writing-useful-libraries-in-php/</a></li>
</ul>

blocks|key|82233|text|分析您的流程！|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|82234|就像分析代码一样，您可以分析您的开发过程。|82235|看一看我们花了最多的时间，并尝试优化你的过程的这一部分。|82236|entityMap^0|0|7|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|P|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|Q|8|@]|D|@]|E|$]]]|K|$]]

Profile your process!

Just like profiling code you can profile you development process.

Look were the most time is spent and try to optimize that part of your process.

blocks|key|1037499|text|我认为你应该读一读布鲁克斯的经典著作“The+Mythical+Man-Month,+Anniversary+Edition”。尽管原著描述了60年代中期完成的工作，但潜在的事实仍然是准确的。后来关于'No+Silver+Bullet‘的论文(包含在周年纪念版中)非常有洞察力。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1037500|简而言之，这本书解释说，随着程序变得越来越大，它们变得更难管理(理解、维护、开发)，因为有更多的事情需要考虑。几乎所有的设计技术和编程技术都试图限制这些问题，但随着软件变得越来越大(这是“没有银弹”副标题的“本质”部分)，问题就存在了。|1037501|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/The_Mythical_Man-Month|1|http://en.wikipedia.org/wiki/No_Silver_Bullet^0|J|17|0|2T|G|1|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]|$A|T|B|U|1|V]]|C|$]]|$1|D|3|E|5|6|7|W|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|X|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]|N|$5|I|J|K|C|$L|O]]]]

I think you should read Brooks's classic book '<a href="http://en.wikipedia.org/wiki/The_Mythical_Man-Month" rel="nofollow noreferrer">The Mythical Man-Month, Anniversary Edition</a>'. Although the original book describes work done in the mid-60s, the underlying truths are still accurate. And the later paper on '<a href="http://en.wikipedia.org/wiki/No_Silver_Bullet" rel="nofollow noreferrer">No Silver Bullet</a>' (which is included with the anniversary edition) is very insightful.

Put succinctly, the book explains that as programs get bigger, they get harder to manage (understand, maintain, develop) because there are more things to think about. Almost all the design techniques and programming techniques around are used to try to limit those problems, but the problems exist as software gets bigger (that's the "essence" part of the sub-title of'No Silver Bullet').

blocks|key|1037540|text|对你来说最大的收获可能来自于：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1037541|版本控制(如Svn、Mercurial、Git等)|1037542|构建服务器(例如Hudson)|1037543|测试|1037544|重构|1037545|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

The biggest bang for your buck will likely come from: 
Version control (e.g. Svn, Mercurial, Git etc.) 
Build server (e.g. Hudson) 
Tests 
Refactoring

blocks|key|1037615|text|冷酷的事实是，开发人员的效率将随着项目规模的下降而下降。这一点早在几十年前就已经知道了。有一些方法可以帮助你，但它们确实需要一些纪律。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1037616|最好的解决方案是进入更高的抽象级别。编写将用作构建块的例程，您可以将其作为标准库或语言构造来使用。记录它们的接口，并且只对接口进行编程。如果你曾经觉得你需要知道你没有在工作的例程是如何实现的，你要么使用错误了，要么没有对接口进行足够的文档记录。缓慢地添加到界面，缓慢地删除任何东西，并记住，改变它的元素可能会严重影响你。|1037617|地点是你的朋友。你越能专注于一小块地方，你就会过得越好。对接口进行编程有助于实现这一点。保持例程的内聚性有助于实现这一点，因此例程一次只做一件事。|1037618|面向对象是非常有用的，因为它促进了以上两个方面的发展。它促进了接口的封装和编码，并将相关的代码片段组合在一起。|1037619|测试驱动的开发对于强制对接口进行编程很有价值。基于接口编写测试，而不是基于实现。这有一个很好的副作用，那就是测试套件本身有助于定义接口。如果它没有被测试过，你就不能指望它。确保你可以轻松地运行测试套件，并养成这个习惯。|1037620|重构将是必要的。做好计划，尤其是在改变任何事情的时候。你需要干净的代码。此外，您将不可避免地发现将功能放在了错误的位置。|1037621|还要记住，所有这些都不会完全解决问题。大型软件项目本质上是困难的。|1037622|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|S|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|U|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|V|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|O|$]]

The cold hard fact is that developer efficiency is going to go down with project size. This has been known for decades. There are methods to help, but they do require some discipline.

The best solution is to go to a higher abstraction level. Write routines that will serve as building blocks, that you can use as if they were standard library or language constructs. Document their interfaces, and program only to the interfaces. If you ever feel like you need to know how a routine you're not working on is implemented, you're either using it wrong or didn't document the interface enough. Be slow to add to an interface, slower to delete anything, and remember that changing elements of it can bite you badly.

Locality is your friend. The more you can focus on a small area, the better off you are. Programming to interfaces helps this. Keeping routines cohesive helps this, so that the routines are doing one thing at a time.

Object orientation is very useful, since it promotes the above two. It promotes encapsulation and coding to an interface, and it groups related pieces of code together.

Test-driven development is valuable for enforcing programming to an interface. Write tests based on the interface, not on the implementation. This has the nice side effect that the test suites themselves help define the interface. If it isn't being tested for, you don't count on it. Make sure you can run test suites easily, and get in the habit.

Refactoring is going to be necessary. Plan on it, particularly when changing anything. You need clean code. Moreover, you will inevitably find that you've put functionality in the wrong place.

Remember also that none of this is going to solve the problem entirely. Large software projects are inherently difficult.

blocks|key|1037654|text|你需要重新设计你的代码构建过程。也可能是你的代码。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1037655|我还建议阅读Code+Complete。|1037656|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

You need to rearchitect your code building process. Possibly your code as well.

I also suggest reading Code Complete.

I initially started off with a small project, editing php files and such in notepad++. It used to be easy to think of a feature, and add it on as a separate file onto the project. As the project became larger, my productivity began to decrease because I couldn't remember all of the functions I made, and where they were stored etc... Then, I added an IDE (PhpEd), and SVN, and then noticed a large boost in productivity. 

I find myself slowing down in productivity again (because everything is becoming too complex again).The project has gone from about 20 or so files --> 100 files, and is becoming difficult to manage all in my head (even using an IDE).
I am wondering if people have advice on what I can do to increase productivity again. (What is the next level? if there is one)

Any software tools or tips on how to approach program design/make things simpler to visualize at least? 

I know there is no silver bullet, but any ideas would be helpful.

For example, do you guys use certain tools to get through the day besides an IDE/SVN. Also, do you write code in a certain way so this won't be a problem in the future? (specifics please).

My productivity is decreasing as the project becomes larger. How to increase productivity as size of project increases?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我最初是从一个小项目开始的，用notepad++编辑php文件之类的。过去很容易想到一个特性，并将其作为一个单独的文件添加到项目中。随着项目变得越来越大，我的工作效率开始下降，因为我不能记住我做的所有函数，以及它们存储在哪里等。然后，我添加了集成开发环境(PhpEd)和SVN，然后注意到工作效率有了很大的提高。我发现自...

问随着项目变得越来越大，我的工作效率也在下降。如何随着项目规模的增加而提高生产率？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问随着项目变得越来越大，我的工作效率也在下降。如何随着项目规模的增加而提高生产率？EN