我为自己和课程完成了大部分小型项目的编码工作，今年夏天最终完成了一个相当大的项目。
作为参考，我正在使用Zend Framework开发一个Web应用程序，我正在与另一个人合作。
我在五月份开始研究它 - 当时，已经写了很多代码（相当邋），我没有太多的控制权。当我开始时，不知道更好，我只是直接在服务器上用vim编辑文件，或者使用eclipse和ftp-ing文件。在这个过程中，我开始使用eclipse进行编辑，使用SVN进行源代码控制并将文件部署到服务器。
我的问题是，有什么其他好方法可以帮助我提高工作效率，还可以更好地管理部署，因为它更贴近使用它的真人？
编辑：实现了我遗漏的两件相关事情。
一个是我一直在消除糟糕/危险的代码，因为我最终触及了使用它的东西。通常最好是专门投入时间，还是我的工作方式通常足够有效？
另外，鉴于我的时间相对有限，单位测试值得付出努力甚至是合适的吗？
编辑＃2：我被提醒我遗漏了项目管理部分。我在决定先打什么方面遇到了问题。我觉得有些日子我花了很多时间来关注仍然需要做的事情而不是实际做的事情。这是常见的，其他人如何处理它？</ p>
我将要做出的改变：我决定做的最重要的事情是实际跟踪需要完成的所有事情。我有一个写得很好的规范，说明最终会有什么，但很多时候我会丢失一些东西并且一遍又一遍地说他们需要完成。现在我会跟踪它们。此外，还要进一步了解测试和部署系统。
答案 0 :(得分：4)
单元测试至关重要：这是唯一可以确保您“在遇到错误的代码时”的方法并不会让事情严重破坏的方法。当你闻到或发现不良代码时，围绕它构建测试，然后继续重构 - 真的是唯一理智的方式来处理legacy code！
您已经在做其他关键方面，例如将代码置于版本控制之下;如果您管理/领导一个大型或分布式团队，我强烈推荐DVCS（hg是我的选择，但是git和bazaar也很受欢迎），但是因为你似乎在自己工作，svn就好了。
持续构建是下一个推荐的做法 - 但是，再次，如果你基本上是独立的，并且只是确保以痴迷的方式运行你的测试套件，那就完全相同了。下一步：良好的releng实践 - 如果在您的代码上报告错误，您必须能够完全重建导致该错误的源，配置等的集合。
你喜欢什么IDE或编辑器 - eclipse，vim，emacs，zend stuff，w / ever - 实际上是次要的。你似乎正在发展正确的直觉 - 对你有益!!! - ）
答案 1 :(得分：3)
危险代码，我建议如果有合理的可能性，危险会咬你的话，应该根除它，以便有时间追踪它并修复它。
Sloppy Code ，在您找到它时进行修复（因为您现在需要专注于将产品投放到截止日期），如果这有任何结果是危险的代码那么如上所述。
单元测试，取决于，如果您有很多使用经验，那么您可能会很有效率。如果不是，那可能会拖累你的时间。只有您可以根据您的日程安排决定权衡是否值得。我建议一些简单的自动化测试可能值得投资，只是为了检查你的应用程序的绝对基础知识是否有效。这可以通过相当高的抽象级别来实现，您可以使用selenium或类似的东西。这可以避免在压力持续时释放任何真正令人尴尬的错误。
如果您要进行自动化测试，最好有一个自动构建过程来运行它们，即持续集成服务器。如果你在构建中有其他步骤，比如编译等，这可以确保这些东西也能正常工作。但是，您的日程安排可能会确定您是立即还是稍后进行设置。我记得有一大堆非常基本的测试从我的IDE运行，不久之后我们有时间为我们的连续构建设置Hudson并且没有回头。
确定工作优先级，可以并不总是知道接下来要做的重要任务。你需要一份所有优秀的清单，我在这里工作的所有内容都在bugzilla。在此之后，你需要对这些事情做出广泛的优先考虑，如果你正在为你的产品v1工作，我建议你制作prirorties v1，v1.1和Road Map。在此之后，您需要决定下一个或几个要处理的事情。根据您想要返回列表的频率，这将是一件事，或一堆。这可能意味着与您的伴侣坐下来并查看列表并确定要做什么以及如何做。有时当我不知道下一步该做什么时，我注意到的一个问题是我实际上不知道我将如何做下一个工作，意识到这通常会让我很清楚接下来的重要事项是什么只需要弄明白该怎么做。
管理工作，如果您有一个地方可以使用新增强功能等，例如bugzilla或user voice，请确保人们使用它而不是期待你把东西放在那里。每周（或任何频率工作）检查新条目并给予优先级。关键是你可以批量处理这些问题，使你免于在他们进来时处理它们的中断。
更好的部署，您说您正在使用svn进行部署。我猜你只是直接到你的生产系统结帐。你现在没有说你是在使用标签还是分支机构。当你进行部署时，我建议在那时进行分支，即如果它是产品的v1，则创建一个v1_maintenance分支。任何错误修复等都会在该分支上进行并合并（定期且频繁地，相信我可能会感到痛苦）进入主干。这使您可以在行李箱上继续充分蒸汽，同时仍然能够支持已发布的版本。您可能希望在某一天查看ant或类似情况进行部署，但如果您现在有一些可行的工作，您可能会更好地花在其他地方
答案 2 :(得分：2)
这个问题被标记为项目管理，但我在这里看不到任何PM类型的问题:)如果我要戴上我的PM帽子片刻，我会说你不管没有一个计划。计划是对您需要开展的所有活动的详细描述。
但是这种方法比其他任何方法都要多，所以我的两分钱就是这样;
答案 3 :(得分：2)
没关系，问题跟踪会占用越来越多的时间。如果您不管理问题（功能/错误/等），您将无法管理项目。由于PM 是一份全职工作，我希望随着项目的发展，你需要花费更多的时间。没关系。拥抱它。不要削减管理成本（即投入时间）（你没有十几个助手，是吗？）。因此，编码进度将越来越慢。没关系。您需要为管理层投入时间，否则项目的质量会下降如此悲惨，您将无法管理。
测试至关重要！但不是单元测试，而是验收测试。单元测试对于质量源代码非常重要。但验收测试对软件质量很重要。在良好的测试框架中投入时间并自动化测试。
最大的问题是需求管理。问题是：经过所有这些更改，功能请求，错误修正等等，这个应用程序在世界上应该如何工作？准确的问题跟踪和验收测试（保持良好的记录）使这个地狱更加舒适。
部署应该是一个详细的过程，每个步骤都已定义并仔细描述。部署每个版本后，应修改和完善部署过程。不玩真人网站。只需按照程序，一步一步。 （作为第一步，您应该“备份网站”。）
但总的来说，你需要一个特殊教育（学校或自学）来做软件项目管理。它与业务相关，并且都与风险缓解有关。是否有其他人与您合作甚至在您的控制之下？然后还有另一个复杂的轴：团队成员之间的关系。那时你需要学习心理学，勇敢而且非常耐心。
答案 4 :(得分：1)
代码：
来源控制 - 做得好，
单元测试
清理坏代码，因为您需要的不仅仅是因为。您应该致力于生产产品而不仅仅是清理代码。如果您要移动到需要执行某些操作的代码区域，请清除。
你提到了一个合作伙伴，考虑结对编程......
管理：
一个。包括任务/功能列表
B中。为他们创建一个时间估计 - 如果任务估计超出了几天的努力，那么您可能需要更多地分解任务。大量时间估计可能表明您没有将问题彻底解决，以至于无法正确估算问题。通常，当这样做时，估计会变得更好。
℃。与您的合作伙伴讨论如何共同管理此工作负载。
d。为每周想要完成的目标设定目标并全力以赴。
电子。对上周进展顺利，没有做什么，我们怎么做得更好，我们怎么能继续做我们做得好的事情进行验尸讨论。
最重要的是，玩得开心！
答案 5 :(得分：0)
如果您不密切关注，PM问题......管理您的活动列表（或收件箱）可能会变得极其无效。在任何时间点处理的最佳项目将取决于;