如何管理大型项目？

Question

我已经为自己和课程完成了大部分较小项目的编码，而今年夏天，我完成了一个相当大的项目。

作为参考，我正在使用开发一个web应用程序，我正在和另一个人一起工作。

我在五月份就开始做这个工作了--那时，我已经写了很多代码(相当草率)，我没有太多的控制能力。当我开始的时候，不太清楚，我只是直接在服务器上用vim编辑文件，或者使用eclipse和ftp来编辑文件。在此过程中，我开始使用eclipse进行编辑，使用SVN进行源代码管理，并将文件部署到服务器。

我的问题是，随着部署越来越接近实际使用的人，还有什么其他好的方法可以帮助我提高生产率，同时也可以更好地管理部署？

编辑:意识到了我遗漏的两件相关的事情。

其中之一是，我一直在消除坏/危险的代码，因为我最终接触到了一些使用它的东西。把时间专门花在这上面是更好，还是我这样做的方式一般都足够有效？

而且，考虑到我的时间相对有限，单元测试是否值得付出努力，甚至是合适的？

编辑2:有人提醒我，我忽略了项目管理部分。我一直很难决定先打什么。我觉得有些日子我花了很多时间来关注那些还需要做的事情，而不是实际去做。这很普遍，别人怎么处理呢？

改变了我要做的：我决定做的最大的改变就是跟踪所有需要做的事情。我有一份写得很好的规范，说明了最终要做什么，但很多时候我会失去一些小东西，反复地说，它们需要完成。现在我会跟踪他们。此外，还将更多地研究测试和部署系统。

Answer 1

危险代码，我建议，如果有一个合理的机会，危险会咬你屁股，这将是值得的时间追踪和修复它。

懒散代码，根据您的发现(听起来您需要专注于在截止日期前生产一个产品)修复它，如果这些代码都是危险的，那么就按照上面的方式处理它。

单元测试，取决于，如果您有大量的经验，您可能会在它的生产力。如果不是的话，这可能会拖累你的时间。只有你才能根据你的时间表来决定这种交易是否值得。我建议一些简单的自动化测试可能是值得的投资，只是为了检查您的应用程序的绝对基础工作。这可以在相当高的抽象级别上实现，您可以使用硒或类似的东西。这只是避免了任何真正令人尴尬的错误被释放时，压力在继续。

如果您要进行自动化测试，最好有一个自动构建过程来运行它们，即一个连续集成服务器。如果您在构建中有其他步骤，如编译等，则可以确保这些步骤也能正常工作。尽管如此，您的计划可能会决定您是现在设置，还是稍后设置。当我想起来的时候，我在IDE上运行了大量非常基本的测试，后来我们有时间为我们的连续构建设置Hudson，而没有回头看。

优先考虑工作，不总是知道接下来要完成的重要任务是什么是正常的。你需要一张清单，列出所有未完成的事情，我的工作都是用布奇拉完成的。在此之后，您需要在这些方面具有广泛的优先级，如果您正在开发您的产品的v1，我建议您制作prirorties v1、v1.1和路线图。在此之后，您需要决定下一件或几件要处理的事情。根据你想要返回列表的频率而定，这是一回事，或者是一堆。这可能意味着和你的伴侣一起坐下来，仔细考虑一下清单，找出该做什么和如何做。有时候当我不知道下一步该做什么的时候，我会注意到一个问题，那就是我不知道下一步该怎么做，我意识到这经常会让我清楚地知道下一步什么是重要的，我只需要弄清楚该怎么做。

Managing ，如果您有一个地方可以进行新的增强等等，即布奇拉或用户语音，请确保人们使用它，不要期望您将它们放在那里。注意每周(或任何频率)检查新条目，并给予它们优先权。关键是，您可以批量处理这些问题，使您从处理它们的中断中解脱出来。

更好的部署，您说您正在使用svn进行部署。我想你应该直接去你的生产系统结账吧。你不会说你现在是否在使用标签或分支。当您部署时，我建议在这一点上分支(如果是产品的v1 )，创建一个v1_maintenance分支。任何错误修复等都会在该分支上进行，并被合并(定期和频繁地，相信我，否则会变得痛苦)到主干中。这允许您继续在主干上的全部蒸汽，同时仍然能够支持发布的版本。您可能想看看蚂蚁或类似的某一天的部署，但同样，如果您现在有一些有用的东西，您的努力可能会花在其他地方。

Answer 2

单元测试是至关重要的:这是确保您的“在遇到错误代码时删除错误代码”的唯一方法，不会破坏任何事情。当您发现或发现错误的代码时，围绕它构建测试，然后继续进行重构--这是处理遗留代码的唯一正确的方法！

您已经在做其他关键方面的工作，例如将代码置于版本控制之下；如果您正在管理/领导一个大型或分布式团队，我强烈推荐DVCS (hg是我的选择，但git和bazaar也非常受欢迎)，但正如您似乎正在自己工作一样，svn也不错。

继续构建是下一个推荐的实践--但是，同样，如果您基本上是独立的，并且确保您的测试套件运行得很疯狂，那么这也是一回事。下一步:好的瑞伦实践--如果在您的代码中报告了bug，那么您必须能够准确地重构导致该bug的源、信任等集合。

您喜欢的IDE或编辑器-- eclipse、vim、emacs、zend之类的东西--实际上是次要的。你似乎在培养正确的直觉

Answer 3

这个问题被标记为项目管理，但我在这里没有看到任何PM类型的问题:)如果我暂时戴上我的PM帽子，我会说没有计划你就无法管理。一个计划是对你需要进行的所有活动的合理的详细描述。

但这比其他任何方法都更重要，所以我的两分钱就是这样的；

1. 绝对要确保您的坏代码实际上是坏的。如果它有效，你确定它的代码是坏的还是看起来很奇怪？
2. 单元测试的价值与您愿意承担的不良代码风险成反比关系。例如，如果我在一家主要的电信公司工作，而我们正在改变我们的计费系统，你他妈的知道我们将测试这一变化而死亡。但是，如果应用程序是次要的，并且您愿意接受修复一个问题的后期生产，那么您可以通过较少的测试。