当自由职业者交付了损坏的代码时该怎么办

当自由职业者交付了损坏的代码时该怎么办

损坏的代码与普通的错误不同。普通的错误出现在大部分功能正常的特性中；损坏的代码可能会阻止发布、阻塞登录或使文件在第一天就无法使用。这种差异很重要，因为你的下一步行动应该与损害相匹配，而不是与你的情绪相匹配。

先问一个问题：任何人都能安全使用它吗？如果答案是否定的，就把它当作交付问题，而不是打磨任务。如果答案是肯定的，但有一条路径失败，那么你可能正在处理一个仍需修正的缺陷。简单，但有用。

什么算作“损坏的代码”与普通错误的区别？

损坏的代码通常以三种形式出现：未完成的工作、不稳定的工作或无法在约定的设置中运行的工作。一个在提交时抛出错误的表单按钮是一个错误。一个因为自由职业者跳过验证、路由文件或所需的API钩子而从未达到支付的结账流程是损坏的代码。

首先查看范围。如果自由职业者承诺了一个页面构建器，但只交付了头部，那就不是一个小缺陷。如果自由职业者交付了一个依赖于从未提到过的文件的脚本，那也不是一个小缺陷。代码可能存在，但交付仍然是损坏的。

一个实用的测试可以帮助判断：代码能否在5分钟内根据约定的结果进行评估？如果你需要隐藏的知识、秘密的设置步骤或私人解释才能使其正常工作，那么问题就比一个打字错误更严重。这是许多客户应该重新审视他们的笔记的时刻，如果需要，可以将问题与 进行比较。如何安全地雇佣自由职业者用于下一个项目。

在联系自由职业者之前，你应该首先检查什么？

在写之前先重现一次问题。重现两次更好。如果可能，使用相同的浏览器、相同的设备和相同的账户。准确记录你点击了什么、发生了什么以及故障出现在哪里。“它不工作”对任何人都太薄弱了。

然后记录环境。记录浏览器名称、版本、操作系统、服务器URL，以及你是使用预发布环境还是生产环境。一个在笔记本电脑上的Chrome中有效的代码路径可能在手机上的Safari中失败，而这种差异可以节省很多后续的来回沟通。

在证据仍然新鲜时收集硬证据：截图、控制台消息、服务器日志、错误ID和故障的时间戳。如果错误在部署后出现，请记录你收到的确切文件或版本。这些细节将模糊的投诉转变为可用的报告。

不要一次更改三件事。如果你编辑配置、替换数据集并重启服务，没人能判断哪个更改导致了故障。保持一个测试路径不变。

你应该如何报告损坏的代码而不让它变成争论？

保持第一条消息简短、事实性和有日期。一个好的结构是：1）什么失败了，2）在哪里失败，3）你期望的是什么，4）你接下来需要什么。这足以开启修复对话，而不会听起来指责。

示例：“在临时网站上，联系表单提交后返回500错误。我期望表单能发送消息并显示确认。我附上了截图和控制台日志。请确认原因并发送修复或更正的构建。”

这样的措辞没有留下戏剧化的余地。它还避免了将责任归咎于自由职业者意图的陷阱，而你无论如何无法证明。关于影响的句子要具体：“客户无法提交订单”，“管理面板冻结”或“导出的文件为空。”这些细节比情感更重要。

如果项目涉及面向公众的工作，消息应清楚提及后果。一个损坏的着陆页可能在几个小时内浪费营销预算；一个损坏的结账过程可能立即导致销售损失。没有人需要戏剧化的段落来理解这一点。

你应该分享什么证据，以便自由职业者能更快地修复？

按顺序发送重现步骤，而不是作为故事。步骤1：登录。步骤2：打开仪表板。步骤3：点击导出。步骤4：下载失败。这种列表让自由职业者可以准确地重现你的路径。

包括触发问题的测试数据，例如演示账户、示例记录或特定文件名。如果代码依赖于语言设置、浏览器扩展或特定环境变量，请提及它。一个缺失的细节可能会浪费一个下午。

分享可交付成果的版本信息。如果你收到的是“v3”，请说明。如果自由职业者在你最后一次审查后推送了补丁，请说明是哪个补丁。如果有私有仓库，请包括分支名称和提交哈希。

文件有帮助，但只有正确的文件才有效。空白屏幕的截图是有用的。如果4分钟的屏幕录制能在一次播放中显示点击和失败，那就更好了。这就是短语自由职业者评价有时变得相关，因为不清晰的交接模式往往在这里出现，然后才会在代码中显现。

你应该在什么时候要求修复、回滚或退款？

根据严重性而不是挫败感选择补救措施。如果错误较小且代码库其他部分可用，请求修复。如果损坏的代码阻碍了发布或损坏了数据，回滚可能是最快的安全措施。如果可交付成果不可用或修复不安全，退款就变得合理。

问一个直接的问题：这能在不损坏项目其他部分的情况下修复吗？如果答案不确定，而自由职业者在猜测，回滚可能比等待更能保护你。一个糟糕的补丁可能会将一个损坏的模块变成三个损坏的模块。

退款不应是消息1中的首要威胁。它们应在对证据和交付条款进行明确审查后再提及。不过，如果工作无法在现场修复，或者自由职业者承认架构是错误的，你应该停止将文件视为仅一步之遥的完成状态。

这里有一个实际的边界。如果一个发布阻碍了收入，每延迟一个小时都会产生成本，即使你没有精确计算到分。如果项目是私人的且风险较低，修复可以等待更长时间。上下文很重要。

如果自由职业者说代码在他们那边工作呢？

不要将这个答案视为争论。将其视为线索。在许多情况下，问题是环境不匹配：一台机器有缓存的依赖项，另一台使用不同的Node版本，或者一台服务器在本地设置步骤后隐藏了缺失的文件。

询问自由职业者使用的确切设置。请求版本号、安装步骤以及他们在克隆或上传后遵循的任何手动步骤。如果他们说“在本地工作”，你需要的是本地的配方，而不是安慰。这才是关键所在。

有时代码依赖于一个无声的假设。自由职业者可能假设存在一个管理员账户，或者假设配置文件已经存在，或者假设数据库中已经包含一个种子记录。这些假设应该被记录下来，但现在的紧急任务是逐一揭示它们。

保持语气平静，即使答案听起来含糊。像“请发送您使用的确切设置步骤，以便我可以与我的环境进行比较”这样的句子就足够了。如果自由职业者合作，差距通常会迅速缩小。如果不合作，您至少知道问题不再仅仅是技术上的。

何时破损的代码成为移交或所有权问题？

当文件到达时没有运行它们所需的步骤，破损的代码就成为移交问题。这包括缺少安装说明、缺少访问细节、缺少环境文件和缺少部署说明。代码可能存在；但所有权却不在。

这种情况常发生在依赖团队而非个人的项目中。开发者发送一个代码库，但服务器凭据存放在私人消息中。设计师交付一个网站主题，但构建工具从未被提及。后端脚本仅在自由职业者的机器上运行，因为其余的设置从未被记录下来。

在这一点上，问题不仅仅是“修复这个错误”。而是“我的团队能否完全采用这项工作？”如果答案是否定的，即使每个文件看起来整洁，交付也是不完整的。这就是“24freelance.pro 网站的规则。freelance可以作为处理工作、文件和沟通的有用参考点。

一些团队在接受项目之前还需要一个转移清单。一行用于访问。一行用于托管。一行用于管理员凭据。一行用于文件夹结构。没有这些，交接可能会失败，即使代码本身是健全的。

你如何防止下次出现相同的交付问题？

在工作开始之前写下验收标准。不是一段话，而是一个列表。“使用有效凭据登录成功。” “导出生成一个包含3列的CSV。” “表单发送电子邮件并显示成功消息。” 这些行使得发现错误代码变得更容易，因为目标是可见的。

提前要求测试用例，特别是对于有两个或更多分支的功能。如果自由职业者知道你将如何测试，他们更有可能为真实的检查而构建，而不是为想象中的检查而构建。阶段审查也有帮助，因为它在任何人称其为完成之前捕捉到错误代码。

用一句话定义“完成”，包括文件、访问和证明。例如：“完成意味着代码在我们的暂存服务器上运行，README列出了设置步骤，测试账户验证了主要流程。” 这个定义不会解决糟糕的工作，但它会使糟糕的工作更早显现。

对于复杂任务，要求提供一份简短的交接说明。即使是5个要点也能为你节省时间：环境、依赖关系、已知限制、测试数据，以及谁负责下一步。小请求，大回报。

最后一个实用习惯：将项目聊天和最终文件列表放在同一个地方。如果自由职业者通过电子邮件发送修复，但部署说明在聊天中，而服务器密码在电子表格中，那么交接就很脆弱。脆弱的交接在压力下会失败。