项目供应/移交

项目供应/移交

最后成为专业人士的艺术

普通的软件开发人员有很多他们已经从事或正在从事的项目，但现在是时候将该项目交给另一双手了。作为我们真正的专业人士，能够多做一步并巩固项目发送方和项目接收方两方之间积极的工作关系是令人钦佩的。作为一个两端都经历过的人，我可以说它可以非常 不专业 当项目的关键部分未披露或根本不存在时。

多年来，我收集了一些有用的见解、技巧和指南，以帮助我尽可能轻松地移交项目。因此，让我们不要再浪费时间，只需深入研究它们。

设置说明

首先，提供关于如何构建和运行项目（如果首先处于可运行状态）的清晰、逐步的文本甚至视频指南。我承认，走视频路线是一个真正的延伸，但在这个时代，它可能比使用说明书有用得多。

就像破解谜语一样，运行第一个构建并在收到源代码后设置所有内容，至少可以说是具有挑战性的。一个小的依赖版本号可以决定一个项目的成败。我参与过很多项目，只要版本不匹配就会导致绝对混乱。甚至在项目成功构建时给出误报，但随后会出现运行时崩溃和警告。为了省去无数视频通话和有关构建和运行项目的正确程序的消息的麻烦，只需节省时间并提供完成该任务所需的最少说明和注释。

容器工具，例如 码头工人 提供了一种起草构建合同的好方法，这种合同可以仅用于此类情况。它消除了披露有关运行平台和依赖项的具体版本名称和代码的需要（我们稍后会回到这一点）。

这里要提到的一件重要的事情是实际上 测试 您在自己、本地机器和其他一些测试机器上提供的指南或容器组件，以确保指南不会遗漏一些关键的关键或步骤。

项目文件

出于某种原因，当另一个开发人员伸手靠近它甚至提到它时，这个神奇而关键的拼图部分往往会躲避甚至蒸发成稀薄的空气。

文档中包含的最少数据应该是：项目是关于什么的，当你开始工作时项目的状态是什么（如果它是一个遗留项目），移交时的项目状态是什么甚至提到潜在的未完成任务或目标，最后，项目最终的原始计划是什么。

如果没有任何文档，写一些。至少有一些描述和项目当前所处的状态。如果项目实际上正在做某事，或者在移交过程完成时它是否可以报废，接收方应该知道最少的知识。

如果有现有的项目文档，请再次查看。检查是否所有东西都在那里，如果缺少您认为可能很重要的东西，请填写。

账户凭证

应提供任何分配的测试帐户凭据或参数，以确保接收方可以尽快探索该项目。

有可能需要为某些敏感服务提供一些完整的帐户凭据。请务必与主管或安全团队（如果可能）确认应如何提供敏感数据。

如果您与其他项目共享帐户，请在移交之前将它们解耦。创建新帐户并选择性地为接收方定制它们。

检查您的 Git 历史日志以了解敏感数据的任何提及或暴露。

第三方服务帐号

清理任何调试数据和工件的任何必需的第三方服务帐户。只需提供一个干净的状态，将最后的日志设置为快照状态。

如果在开发和生产过程中使用了云服务，在提供项目时，请清除之前的日志和数据的任何痕迹。某些服务可能不提供此功能，在这种情况下，您可能会考虑创建新帐户并在移交过程之前迁移到它们。向对方提及这一点，也许他们有自己的现有帐户可以使用，甚至可以创建可以与您共享的新帐户以更新项目。

当提及用户数据时，请确保您遵守任何 GDPR 法规。如果可能，请咨询更熟悉此主题的法律程序的人。

API 文档

可以想象，如果一个项目包含或以 API 服务为目标，那么存在一些文档或提及所有可能的调用和端点，但在这里，没有文档只是对某些外部信息源的神秘调用。是时候举起袖子开始自己编写一个基本的 API 文档了。

这似乎是很多不必要的工作，尤其是对于那些可能没有积极参与 API 开发过程的人来说。别担心，这就是我们在这里的原因。有一些有用的工具可以让生成 API 文档变得更容易一些。 邮差 可以成为开始或在线搜索替代品的好工具。如果使用 Postman，请务必共享 API 收藏 和 环境 .

尝试打印网络日志，看看您可以从中提取哪些数据并从那里开始。请务必记下任何错误状态和网络响应。

围绕单个 API 调用写入的最少数据应该是：

• 网址
• 调用方法
• 请求具有潜在查询或路径参数的数据
• 响应数据

代码清理

为了清楚起见，您不需要急于完成或修复代码。没有那样的事。您应该做的是清除敏感评论和调试消息。应检查并仔细检查您和/或您公司的任何琐碎参考。需要说，删除任何课程单词和粗鲁/愚蠢的评论或属性名称。只留下提供代码本身价值和信息的注释。

在整个代码库上运行标准化的代码格式化程序，确保代码呈现方式的一致性。

重构任何文件、类、方法、字段和属性名称，以更好地反映它们提供的功能。对整个项目进行全局搜索，查找您认为在移交之前删除的重要关键字。

源代码

与上一部分直接相关的是，源代码可能是移交过程中最关键的部分。接收方可能主要对源代码感兴趣，但正如我们在本文档中看到的那样，这个关键组件可能会被围绕它的许多缺失或不完整的部分所掩盖。许多 IDE的 提供一种导出项目源代码的方法，使其更易于解包和运行。导出它们并以不同的名称再次导入它们，只是为了模仿项目新手可能会如何体验该过程。

如果部分或整个代码本身应该受版权保护，请确保它确实是。检查措辞和日期值。任何专有库或模块，或其他受不同版权或许可约束的东西，请务必向接收方披露。

二进制文件或工作示例和工件也很受欢迎。

Git清理

哦 吉特 ，如果没有这个工具的安全带，我们会在哪里。 Git 知识几乎是一种艺术形式，知道如何使用它的人越多，它就变得越有价值。

Git 或任何其他 VCS 都提供了对各个开发阶段的独特快照。所有不同的分支、提交消息和合并请求都旨在实现一个单一的结果，即整体上更好的项目。

一个项目越成熟越复杂，Git中存储的信息就越多 日志 .很有可能旧的、临时的甚至已弃用的分支只是坐在那里而没有被合并到另一个分支中，或者只是被标记为要删除，但实际上从未完成该任务。遍历 Git 树并确保只剩下必要的分支。我不会详细介绍合并或重新建立分支，还有更多可用的资源 在线的 关于该主题，但简单地说，重新定位以一条进展线结束，并且可能更容易理解，并且合并显示了每个合并分支所形成的路径。

如果 Git 历史记录包含大量敏感信息，那么要做的一件简单的事情就是从最新的分支创建一个新的存储库并按原样提供。如果被问及日志信息的缺乏，只说讨论这些事情超出了你的工资等级。

资产

资产可以是任何文档、注释、图形元素、字体、翻译等，它们不一定被认为是文档的重要组成部分，但仍然可以为刚开始项目的人提供很多价值。例如，如果我们提供用于项目中图形元素的 Photoshop 模板或设置，它会非常有用。

UX 设计草图、颜色代码、测试策略和方案可以加快许多繁琐的任务，以匹配其他文档中提供的确切规范。我并不是说你应该绝对提供 每一个 一个小小的头脑风暴涂鸦，只是在忙碌的项目移交过程中可能被遗忘的资产。

单一存储库

我还没有看到一个开发人员喜欢有人向他们分享一堆链接以及分散在各处的文件和文档。创建一个单一的资产存储库，您可以轻松地将其链接并共享给任何需要它的人。通过使用单个存储库，您为其中包含的文件创建了一个单一的事实来源。在与外部资源共享之前，应禁用存储库中包含的文件的任何写入/编辑。

另一个步骤是定义一个明确的时间窗口，该存储库可供读取/下载。任何存储库都不应无限期地向任何外部方开放。时间窗口过去后，应生成内部备份副本并删除存储库。

个人过渡指导

在文件中清楚地说明，如果可能的话，在口头对话中说明您是否可以为开发团队的新成员提供个人指导或辅导。如果您有空，请务必说明您的空闲时间和可以联系您的时间范围。对此要非常清楚，您不需要就不再从事的项目进行清晨电话会议。时间窗口取决于项目的大小（项目越大，时间窗口越大），但从交接之日起几乎不能超过一个月。在那之后，您是否可以参与有关该项目的讨论取决于您的个人感受。

您也可以提供有偿支持，但这在很大程度上取决于您与开发项目的公司签订的工作合同，或者您是否是自由承包商。

快照版本名称（可选）

虽然我们已经提到了容器和依赖版本控制，但最好也写出您在本地机器上使用的工具和平台的版本名称和代码。例如：Visual Studio Code 版本、使用的扩展、Linux 发行版（如果在 Linux 系统上开发）、Git 版本等。

有用的提示（可选）

像任何其他可选步骤一样，通过分享一些有用的技巧来超越并展示对项目的奉献精神是很好的。我通常会建议分享一些你自己希望有人在加入项目之前告诉你的技巧。几乎所有项目都有自己的特殊“怪癖”，在披露细节时通常会忽略这些“怪癖”。有时一个项目有一些不可预测的状态，可能会给新开发人员造成混乱。将它们写下来并确保向接收方提及该文档，因为许多开发人员倾向于忽略不是整个项目不可或缺的文档（例如 API 文档）。

独立开发者过渡

那么当接收方是你，或者更好的是，没有接收方时该怎么办？到目前为止提到的一切仍然有效。如果您暂停项目一段未指定的时间，请确保当您需要重新开始时，您会轻松完成。如此多的开发人员可以确认他们在 6 个多月后回到项目时遇到了一些“障碍”。事实是，他们中的许多人在那个时期已经进化和转变，并且产生了不同的方法和新的体验，而旧版本的他们当时根本不知道。所以，当他们用“新鲜”的眼光打开旧项目时，各种事情都会“流行”起来，甚至迷失方向。那时查看一些文档确实可以提供帮助。

顺便说一句，如果他们对自己编写的代码感到迷失方向，那么您认为一个完全的新手在没有任何指导的情况下查看该代码后会有什么感觉？

取消项目

当我们不得不无限期地搁置一个项目时，总是令人心碎。取决于到那时为止对项目投入的热情、动力和努力，这可能会非常令人沮丧甚至悲伤。还有一种可能是一个项目只是坐着占用了存储空间。所以这就是为什么必须做好充分的准备，并重复我之前提到的大部分相同步骤。

如果您在某处列出了日落项目（可能是投资组合），请务必使用最后的注释更新其状态。检查任何指向该项目的链接并将其删除。如果项目托管在第三方服务上，请寻找先关闭项目然后最终将其删除的选项。导出源代码文件、资产、构建脚本，将它们压缩并存档。

有可靠的数字资产组织系统，称为 帕拉 方法。 para 代表项目、区域、资源和档案。它是一种很好的方式来看待每个项目并定义，例如不同项目的共同属性。如果遵循这种方法，在终止项目时，只需将项目从“项目”类别移动到“存档”类别，就可以了。

我不建议彻底删除有关项目的存储库和文件。尽管出于某种原因再次修改该项目的机会非常渺茫，但人们永远无法知道。也许只有一种资产需要另外一种。

不好的例子

我们已经看到它在行业中一直在发生。公司购买其他公司，然后了解产品的问题。当初始产品易手时，开发人员和其他员工辞职。

对代码的占有欲非常普遍，在项目人员（不仅仅是开发人员，整个团队）过渡时，应该始终考虑到这一因素。

错误地描绘项目的当前状态并“掩盖”它的一些问题方面，可能会对新团队成员造成破坏性影响。 “在移交之前进行代码审查或演示。”- 你可能会建议，但事情是这样的，大型项目具有非常难以分析的“奢侈品”，因为查看每一个项目所花费的时间的绝对前景细节。例如，购买者只对购买产品的单一功能感兴趣，而不关心围绕该单一功能的所有内容。这导致提前进行收购，而团队是最后收到通知的团队之一。不用说，当时为移交做准备的时间和热情都非常低。

如果您曾经听到过这样的回答：“代码就是文档”，在您询问任何缺少的文档时，您理所当然地应该感到不快。文档 是 文档，其他一切都是额外的。可悲的是，这是一种非常常见的情况，我们应该至少通过为自己树立榜样来尽可能减少这种情况。由于您已经在这里，阅读本文，您已经迈出了成为比本段开头提到的答案的人更好的专业人士的第一步。好工作！

最后的笔记

帮自己和他人一个大忙，加倍努力，确保您已尽一切努力使过渡过程按计划进行。

你有什么好的和坏的项目交接的例子吗？我期待听到他们的消息，也期待听到你对这个主题的看法。如果您觉得有趣，请务必评论并分享这篇文章。

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明

本文链接：https://www.qanswer.top/18452/29100608