准备好交付项目时需要注意哪些事项？

我目前是相当大的Web应用程序（ASP.NET MVC堆栈，大约150K +代码行）的唯一开发人员/架构师，开发工作即将结束。因此，我开始考虑为完成该项目需要做什么，并且我想确保自己为将来必须维护该项目的任何人做正确的事情。

准备将项目移交给维护的其他开发人员或开发人员团队时，需要注意哪些事项？

恕我直言，如果您只能在直接（或间接）交付项目之前做一件事，我建议您仔细检查一下它是否可以从源代码管理中直接编译。

不好笑，但是我无法告诉您我从源代码管理中获得了“最新”多少次，并且未能编译，后来才发现我不在“弗雷德的旧盒子上”，因为代码显然“仅”在Fred的旧盒子上编译”。我什至曾经让一位前雇主立即从多维数据集上删除我的桌面，并用“弗雷德的旧盒子”替换了它，以便我可以从事我想做的项目。

作为上述建议的扩展，因为有时不一定只有最新才能编译应用程序，所以我建议您创建README.txt并将其放在应用程序的根目录中，并将其放在源代码管理中。该自述文件应包含无法检查到源代码管理（如果存在）的外部依赖项列表，如何设置数据库以及有关应用程序的编译，执行或部署周期的任何其他问题。

除了以上两个建议之外，任何其他建议都只是小菜一碟，但是恕我直言，对于任何大于“ Hello World”的项目，以上两个几乎都是必需的。

编辑：

关于文档主题...

多年来，为了简化开发人员的过渡，我已经撰写并阅读了相当一部分的软件文档。我会说这样的文件很少值得在上面打印。开发人员（包括我本人）在编写此类文档时很少考虑应用程序的重要部分，而我们只会倾向于考虑我们所抗争的最新动向。这些文档往往不能涵盖软件的所有重要方面，因此它们很快就会过时。一旦文档过时了，未来的开发人员很可能会完全忽略它，而不是将其备份以适应实际情况（请考虑不断变化的需求）。

建议使用单元测试代替本身的文档。我知道这可能听起来有些陈旧，但是让代码为您做文档。损坏的单元测试比Word文档更难忽略（更容易发现）。此外，英语在表达软件设计的精要要点时非常不准确。甚至有很多简单的方法来解释最简单的英语句子的意思，这只会导致混乱和/或错误。

这就是为什么注释没有代码味道的原因。这也是为什么我们应该记录代码的原因。

您应该确保拥有可靠的文档。有些程序可以根据注释的格式和编程语言从注释生成文档。

考虑接管时您想要有关库或代码库的哪些信息。请一位程序员程序员快速浏览一下，看看他们是否发现任何明显的问题。

祝好运！

确保您的代码只需一次单击/单击即可以最终形式编译和打包。

我无法赞成这个答案。当准备好交付一个项目时，需要注意些什么？够了，所以我必须再次写下来。

我对这种一键式编译非常挑剔，因为我已经花了很多时间弄清楚如何实际编译或打包项目，而我只需要修复一个小错误。我开始将少量批处理/ bash脚本放入项目中，以打包最终的ZIP，JAR或EAR。

除此之外，我还将README.txt添加到根目录中，该目录描述了总体设计，复杂部分和项目环境（与其他部门或人员进行沟通）。

我试图使README.txt保持较小，因为如果您要修复的错误，对其进行编译和打包，则没人会阅读200多页的规范文档。实现细节记录在单元测试中，因此无需将其全部写下来...

我的默认切换清单：

1. 从VCS签出干净副本
2. 测试构建，测试部署
3. 重命名Maven仓库以进行仓库备份
4. 再次测试构建
5. 从zip安装应用服务器的新副本
6. 验证服务器设置说明
7. 再次测试部署
8. 确认没有禁用任何单元测试
9. 扫描注释中的四个字母词，将其删除

如果有任何损坏，我将在交接之前进行修复。在您获得项目的那一天，没有任何事情可以使某人开始运行，然后使项目检出，构建和运行。