我最初开始使用一个小项目，编辑php文件，例如记事本++。过去很容易想到一个功能，并将其作为单独的文件添加到项目中。随着项目变得越来越大，我的生产力开始下降，因为我记不起我所做的所有功能，以及它们存储在哪里等等......然后，我添加了一个IDE（PhpEd）和SVN，然后注意到了大大提高了生产力。
我发现自己再次放慢生产力（因为一切都变得太复杂了）。这个项目大约有20个左右的文件 - ＆gt; 100个文件，并且变得难以管理（即使使用IDE）。 我想知道人们是否就如何再次提高生产率所做的建议。 （下一个级别是什么？如果有的话）
关于如何进行程序设计的任何软件工具或技巧/至少可以使事情变得更简单？
我知道没有银弹，但任何想法都会有所帮助。
例如，除了IDE / SVN之外，你们是否使用某些工具来度过这一天。另外，您是否以某种方式编写代码，以便将来不会出现问题？ （具体细节）。
答案 0 :(得分：12)
绘制和/或写出来。如果你说它“全在你脑中”，那么请花一些时间远离编码并记录你的工作。这可以包括解释你为什么做某事的段落。
图表和其他视觉效果也可以帮助您保持井井有条。
我发现一些程序员忽略了项目中的非技术因素。对于没有组结构来指导它们的单独开发人员来说尤其如此。您的工作不仅仅是代码，您应该查看流程的所有方面。
答案 1 :(得分：9)
永远不要为在记事本中编辑代码感到自豪！ IDE节省您的时间并提高您的效率。 当项目变大时，您应该关注项目管理并坚持高效的“流程模式”，例如RUP（Rational Unified Process），EUP或OOSP。您的SVN是SCM的一部分。当然，模式中定义的活动要多得多。对于文件管理问题，您可以将它们分成不同的包并将它们保存在不同的位置。如果您对“软件工程”一无所知，可以参考Scott W Ambler或其他人撰写的有关SE（软件工程）的书籍。请记住，软件远不止代码！
一个优秀的开发人员知道开发比编程更多。 一位优秀的开发人员知道开发不仅仅是开发。作者：Scott W Ambler
答案 2 :(得分：7)
测试驱动开发可能对您有用。
首先构建测试，然后编写代码以通过这些测试。
当您添加/更改任何代码时，您可以运行回归测试套件以确保您没有破坏某些内容。根据我的经验，这可以节省大量时间，特别是当应用程序的复杂性和大小增加时。
答案 3 :(得分：6)
冷酷的事实是开发人员的效率会因项目规模而下降。这已经数十年了。有一些方法可以帮助，但它们确实需要一些纪律。
最好的解决方案是进入更高的抽象级别。编写将用作构建块的例程，您可以将它们用作标准库或语言构造。记录其接口，并仅对接口进行编程。如果你觉得你需要知道你没有使用的例程是如何实现的，那么你要么使用它错误，要么没有足够的文档记录。添加到界面的速度很慢，删除任何内容的速度都很慢，请记住，更改它的元素会让你感到非常痛苦。
地方是你的朋友。你越专注于一个小区域，你就越好。接口编程有助于此。保持惯例的凝聚力有助于实现这一目标，以便日常工作一次做一件事。
面向对象非常有用，因为它促进了上述两个方面。它促进了对接口的封装和编码，并将相关的代码片段组合在一起。
测试驱动的开发对于强制执行接口编程很有价值。根据接口编写测试，而不是基于实现。这具有良好的副作用，测试套件本身有助于定义界面。如果没有进行测试，则不要指望它。确保您可以轻松运行测试套件，并养成习惯。
重构是必要的。计划，特别是在改变任何事情时。你需要干净的代码。而且，您将不可避免地发现您已将功能放在错误的位置。
请记住，这一切都不会完全解决问题。大型软件项目本来就很困难。
答案 4 :(得分：5)
大型代码库的生产力不仅仅与工具有关，而且与您编写的代码有关。花时间提高新代码和现有代码的质量。是的，它会在短期内减慢你的速度，但它可以让你随着时间的推移保持你的步伐。
无论您的工具或语言如何，这都适用。世界上最好的工具不会帮助那些外出捣乱的人。首先，我会记住一些简单的想法：
有关如何设计优秀代码的更深入信息，我建议您浏览here。
答案 5 :(得分：5)
我曾经在一个拥有大约一百万行代码（C＃，C ++）的项目上工作，而且它还在不断增长。
1）为了管理这样的代码库，svn存档的文件夹结构是以模仿我们产品的各种架构层的方式创建的。通过这种方式，我们可以更轻松地找到存档文件。
2）我们也有自己的自定义构建工具。如果您拥有庞大的代码库，那么在您想要测试小功能时随时构建所有内容可能是不可行的。我们的自定义构建工具有很多选项，可以以任何粒度构建存档。
3）通常我所观察到的是，如果你正确地获得了通用功能/助手，那么在它之上构建新东西变得更容易，并且还可以避免代码膨胀。
4）如果开发项目的开发人员数量更多，请设置wiki。如果做得好，Wiki文档很容易，搜索能力和帮助。
这就是我现在所能想到的。希望这有帮助
答案 6 :(得分：4)
答案 7 :(得分：3)
我认为你应该阅读布鲁克斯的经典着作“The Mythical Man-Month, Anniversary Edition”。虽然原书描述了60年代中期所做的工作，但潜在的事实仍然是准确的。后来关于“No Silver Bullet”的论文（包含在周年纪念版中）非常有见地。
简而言之，该书解释说，随着程序变得越来越大，它们越来越难以管理（理解，维护，开发），因为有更多的事情要考虑。几乎所有的设计技术和编程技术都被用来试图限制这些问题，但随着软件变得越来越大（这是“无银子弹”子标题的“本质”部分）存在问题。
答案 8 :(得分：3)
围绕那个OOP的神话会如何挽救这一天呢？如果这是真的，为什么Linux /内核人员仍然每周推出新版本？换句话说，所有ASM / C程序员都注定要“Hello World”的复杂性？
不确定你究竟要求的是什么。我的意思是在问题出现之前和之后对问题进行研究：
如果你有许多文件和LOC只是减少和重新组织它们。例如，通过为某些任务构建或使用坚如磐石的框架（PDO而不是mysql（））。换句话说，不要重复自己。简短，引人注目，类似的函数名称：get_user_ID（），get_task_ID（），db_query（）....
小组中的沟通是一个问题吗？尝试wiki，尝试内部IM，尝试使用更多评论，询问小组他们不喜欢什么，并希望得到改进。这完全取决于项目。
如果你在一个小组工作，不要到处都是。处理您的零件并改进它们。这样可以节省您进入其他程序员心态所需的时间。一次改变一次。不要打开200个文件并编辑完全无关的内容。
自动化并加速一切，如果可能的话：部署，版本控制，文档，测试。
大项目是大项目，这些项目总是很难完全理解。 KISS很好，但根据我的经验，有时候只需要通过XML，语言特定的接口等来分解独立工作组件的事情......简而言之：从大项目中做出很多小项目。
我将个人待办/记忆清单保存为“myname.todo.txt”。
快速部署是强制性的！例如，安装本地灯/ xampp并直接查看更改。
答案 9 :(得分：3)
正如Steve McConnel所说，编程的主要挑战是管理复杂性。
您有多种方法可以管理它：
在我个人看来，前两点（工具和技术）确实很好，但不是真正改变的东西。例如，我的团队中有同事使用旧编辑器，并且几乎与使用Eclipse的同事一样高效 另一方面，另外两点将有更多帮助：纪律，良好的设计和重构将有助于保持尽可能低的复杂性，良好的团队合作可以解决更大的项目，而这些项目本身就太复杂了。
然而，正如你已经指出的那样，没有银弹。最后，任何成功软件的复杂性都会增长到需要全新一代的维护成本太高的程度 这就是软件生活： - ）
答案 10 :(得分：3)
养成定期研究代码并寻找消除重复的方法的习惯（即应用“不要重复自己”或“干燥”原则），并且无情地重构那些重复。将公共代码片段推送到可重用的方法和类中的次数越多，编写新代码就越容易，并且您在问题上获得的利用率就越高。
使用优秀的 IDE 将帮助您找到共性并应用重构。
还要寻找能够自动化软件各个方面的开源框架和工具。使用它们是DRY原则的大量应用。
答案 11 :(得分：3)
我的第一个想法是你需要写下来。你对“这一切都在我脑海中”的评论让我担心
我发现一个wiki，即使我是唯一的用户，也非常有助于组织我的想法。编辑过程简单快捷，这让我可以将我脑中的内容转化为可搜索的数字媒体。
选择哪个维基并不重要，只需要花一些时间来真正学习语法，这样就不会经常将注意力转移到格式化上。
然后坐下来转储。
一旦你在页面上有了东西，你就可以开始重新组织你的想法了，当你面前就可以更容易地看到整个系统架构。
我还发现了很多聪明而有趣的方法来修复我的架构，只需在完全不同的介质中将它全部放在我面前。
答案 12 :(得分：2)
当然，首先使用oo编程和继承。接下来，我会使用类似代码点火器的框架来启动，添加模块进行布局（这样你就可以拥有一致的网站布局），也许很少有其他人，点不是花太多时间在常见的事情上。 CI的不幸迁移并不是很好，但它们存在，所以沿着这些方向的某些东西对于处理db很有用。 有了这些，您可以再次提高工作效率，因为您不会花时间处理小事。
对于更大的项目而言，它们有多个方面，存在的越多，您需要花费的时间就越多。
希望这有帮助。
答案 13 :(得分：2)
在这里继续下去，但在较小的项目/ API /模块/包/程序集中打破项目（按照你想要的方式调用它们）应该是这里的下一个合乎逻辑的步骤。
人类的大脑只能同时处理这么多东西，我们的工作记忆可以处理得非常多。隐藏较高抽象级别背后的较小细节将使您忘记这些文件，直到引擎盖下出现问题为止。如果发生这种情况，你只需要打开那个特定的引擎盖来修复它。使用不同级别的抽象，你的项目将突然变得更小，只有少数几个单位才有意义，而其他单位只是让它们有效。 OOP非常善于隐藏实现细节，同时暴露更高级别的功能主义者。这就是说，你可以选择其他范例而不是OOP。
此时我给你的建议
这将使您能够大幅减少您需要记住的项目数量，并且可以很好地扩展到下一个数量级。
然后，您的下一步将更深入地研究OOP并了解架构和设计模式。它们将帮助您减少系统的更多域名。
有用的花絮
答案 14 :(得分：2)
在我看来，你有一个庞大的PHP项目。它可以完成，但你真的需要组织。
尽可能将其分解为独立的部分，每个部分只有一个小的界面。
尽可能“完成”。然后将“已完成”代码视为API，因此您不必再查看它了。一周4.5天，假设有人写了它并且你只知道界面。
答案 15 :(得分：2)
我发现测试驱动开发（TDD）/行为驱动开发（BDD）可以帮助我随着它们变大而保持秩序。即使您只是编写单元测试，不考虑功能，集成和其他测试，仅此一项就可以提供巨大的帮助。当你的代码基础变成一个笨拙的，混乱的毁灭沼泽事物时，你的测试将使它在或多或少正确的方向上保持晃动，并防止它绊倒在岩石上，面朝下淤泥，并淹死，因为它也是很难起床。
如果你写了足够的测试并且他们经过深思熟虑就可以做到这一点，这样你就可以做出改变并立即知道改变是否有所改变。如果没有测试，在某一点之后你就无法改变任何东西。
我不太了解PHP场景，但似乎有PHP的测试框架，包括一个名为PHPUnit的框架。
答案 16 :(得分：2)
使用PHP MVC框架将大大减少您需要跟踪的代码量。它将处理您可能必须自己编写的许多内容，如会话，数据库层等。通过使用框架，它将帮助您逻辑地组织文件。
答案 17 :(得分：2)
无类型和程序语言在大型项目中崩溃。一直都是这样，这就是OO制作的原因，解耦和封装之类的东西被认为是很好的设计方法。
答案 18 :(得分：1)
不要假装你可以把它全部记在脑后。在某些时候（看起来你已经达到它），它根本不再可能。 如何处理一个太大而无法记忆的项目？好吧，就像你处理由另一个人写的项目一样，或者你写的是由其他人维护的项目。
最重要的一项：写出好的代码。为类，方法，变量等使用一致，有意义的名称。编写与名称完全相同的函数（相应的方法），不多也不少。没有棘手的捷径，意想不到的副作用，定时炸弹，惊喜。您必须能够自信地使用函数，而无需阅读其实现来检查它的作用和方式。
整理您的代码。从业务逻辑代码中分离GUI代码。将它们保存在单独的文件夹如果文件包含两者，请重构它。如果您已生成代码，请将其保存在单独的文件夹中（这样您就不会想要修改它）。
使用版本控制系统。 （不能经常说）
答案 19 :(得分：1)
描述您的流程！
就像分析代码一样，您可以描述开发过程。
看起来花费的时间最多，并尝试优化流程的这一部分。
答案 20 :(得分：0)
PHP中的大项目？不只是银子弹，没有铅弹，甚至没有粘土子弹。
不同的语言！
答案 21 :(得分：0)
最大的收获可能来自于：
版本控制（例如Svn，Mercurial，Git等）
构建服务器（例如Hudson）
测试
重构
答案 22 :(得分：0)
您需要重新构建代码构建过程。可能也是你的代码。
我还建议阅读Code Complete。