The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
你有一个分配给你的任务，但你不喜欢它。你只是没心情。你不知道如何修复那该死的错误。你不知道那该死的模块是如何设计的，也不知道它是如何工作的。但你必须解决这个问题，而这个问题是由一个对这个软件一无所知的人报告的。你变得沮丧，并责怪那个愚蠢的项目经理和两年前被解雇的程序员。你花了几个小时才弄清楚代码是如何工作的。然后又花了更多的时间来尝试修复它。最后，你错过了截止日期，大家都责怪你。经历过这样的事情吗？
然而，有一种替代方法可以从这种情况中得到专业的解脱。以下是我建议在 Zerocracy 项目中和我一起编码的同行们采用的一些建议。简而言之，我将解释如何取巧并保持专业，1) 保护你的神经，2) 优化项目的开支，3) 提高源代码的质量。
以下是你可以选择的选项列表，按优先顺序排列。我建议你从列表中的第一个开始，并在必要时继续往下。
这是第一种也是最可取的选择。如果你无法解决问题或实现新功能，那是项目的问题，而不是你的问题。即使你无法解决问题是因为你对Ruby一无所知，而他们却雇佣你来修复Ruby on Rails代码库中的错误—这是他们的问题。当你一无所知时，他们为什么要雇佣你呢？
所以要保持积极的态度，不要责怪自己。如果你不知道这段该死的代码是如何工作的，那是代码的问题，而不是你的问题。良好的代码易于理解和维护。
不要试图解决混乱的代码；向厨师抱怨并要求他或她做一些更好的菜（顺便说一句，我喜欢意大利面）。
你该怎么做呢？制造依赖—抱怨不清晰的设计、缺乏单元测试、缺少必要的类等等的新错误。要有创造性和冒犯性—当然要以建设性和专业的方式。不要人身攻击。无论是谁做的这道意大利面，你没有针对他或她个人的意思。你只是想要另一道菜，仅此而已。
一旦你报告了这些依赖关系，在主要任务中解释说在解决所有依赖关系之前你无法继续工作。你将合法地停止工作，其他人将改进你所需的代码。稍后，当所有依赖关系都解决并且代码看起来更好时，再尝试回过头来处理它。如果你仍然发现问题，创建新的依赖关系。持续这样做，直到你面前的代码变得干净且容易修复。
不要成为英雄—不要急于修复你继承的糟糕代码。像一个开发者而不是一个黑客一样思考。记住，作为一名纪律工程师，你的首要和最重要的责任是帮助项目揭示可维护性问题。如何修复这些问题是项目经理的责任。你的工作是揭示问题，而不是隐藏问题。通过成为英雄并试图在一个任务的范围内修复一切，你并没有帮助项目—你只是掩盖了问题。
编辑：另一个很好的依赖关系的例子可能是在Stack Overflow或第三方库的用户列表中提出的问题。如果你无法自己找到解决方案，并且问题超出了你的项目范围—向Stack Overflow提交一个问题，并将其链接放在源代码中（例如在JavaDoc块中）。
所有的依赖关系都已解决，代码看起来很清晰，但你仍然不知道如何修复问题或实现新功能。它太复杂了。或许你只是不知道这个库是如何工作的。或者你以前从未做过类似的事情。无论如何，你无法继续下去，因为你不理解。为了理解，你需要很多时间——比你的项目经理或Scrum团队给你的时间要多得多。你该怎么办？
再次，请积极思考，不要责怪自己。如果软件对于一个完全陌生的人来说不够清晰，那是“他们”的错，而不是你的错。他们以一种难以消化和修改的方式创建了这个软件。但代码是干净的；它不再是一团乱麻。它是一只完美煮熟的龙虾，但你不知道如何吃龙虾！你以前从未吃过。
厨师做得很好，他煮得很好，但餐厅没有给你任何关于如何吃这样一道复杂菜肴的说明。你该怎么办？
你要求一份说明书。你要求文档。设计良好且编写完善的源代码必须有适当的文档。一旦你发现有些东西对你来说不清楚，建立新的依赖关系，要求对代码的某些方面进行更好的文档化。
再次，不要试图自己理解一切成为英雄。当然，你是个聪明的人，但项目并不需要一个聪明的人。项目需要可维护的代码，甚至可以被不如你聪明的人轻松修改。所以请为你的项目好好做一件事：揭示文档问题，并要求有人为你修复它。不仅为了你，也为了大家。整个团队都将受益于这样的请求。一旦文档修复好了，你将继续你的任务，每个人都将得到比以前更好一点的源代码。双赢，不是吗？
现在代码很干净，文档也足够好，但你还是遇到了困境。怎么办呢？嗯，我是测试驱动开发的忠实拥护者，所以我的建议是创建一个能重现bug的测试。基本上，无论是bug还是功能，你都应该以此开始每个任务。通过单元测试来捕捉bug！通过新的测试来证明bug的存在，使构建失败。
这可能相当困难，特别是当你试图修复或修改的软件是由一个对单元测试一无所知的人编写的时候。有很多技术可以帮助你找到使这种软件更具可测试性的方法。我强烈推荐你阅读Michael Feathers的《与遗留代码高效工作》。有许多不同的模式，其中大部分都是有效的。
一旦你成功重现了bug并且构建失败，就停在那里。这已经足够作为一项工作。跳过测试（例如，在JUnit 4中使用@Ignore注解）并提交你的更改。然后在刚刚创建的单元测试中添加文档，最好以@todo的形式。在那里解释你成功重现了问题，但没有足够的时间来修复它。或者可能你只是不知道如何修复它。要诚实并提供所有可能的细节。
我相信通过单元测试捕捉bug，在大多数情况下已经成功的80%以上了。其余的事情更简单：只需修复代码使测试通过。把这个工作留给其他人。
很多时候你根本无法再现一个错误。这不是因为代码无法进行测试，也不能用于单元测试，而是因为你无法再现错误的情况。你知道代码在生产环境中崩溃了，但你无法在测试中崩溃它。用户或生产日志系统报告的错误堆栈跟踪无法再现。这是非常常见的情况。你该怎么办？
我认为在这种情况下最好的选择是创建一个能证明代码按预期工作的测试。测试不会失败，构建将保持干净。你将把它提交到代码库中，然后…报告问题已解决。你会说所报告的错误在现实生活中并不存在。你会声明没有错误——”我们的软件工作正常；这是证据：看我的新单元测试。”
他们会相信你吗？我不这么认为，但他们别无选择。他们无法进一步追究你。你已经做了一些事情——创建了一个新的测试来证明一切都很好。工单将被关闭，项目将继续进行。
如果以后在生产环境中出现相同的问题，将会报告一个新的错误。它将与你的工单关联起来。你的经验将帮助某人进一步调查这个错误。也许那个人也无法通过测试捕捉到错误，也会创建一个新的成功但“无用”的测试。这可能会一次又一次地发生。最终，这种累积的团队经验将帮助最后一个人捕捉到错误并修复它。
因此，一个通过的新测试是对无法通过单元测试捕获的错误的良好回应。
有时候单元测试技术行不通，主要是因为某个错误太重要而不能被忽视。当你向他们展示证明该错误不存在的单元测试时，他们不会同意你的观点。他们会告诉你，“当我们的用户试图下载PDF时，他们得到的是一个空白页面。” 他们还会说，他们并不在乎你那些可恶的单元测试。他们所关心的只是那份应该可以下载的PDF文件。所以，单元测试的把戏行不通。你该怎么做呢？
这取决于很多因素，而大多数这些因素并不是技术性的。它们是政治、组织、管理、社交等等。然而，在大多数情况下，我建议你禁用那个有问题的功能，发布一个新版本，并关闭该问题。
这样你就把问题从自己肩上卸下来，每个人都会感到高兴。嗯，除了那个可怜的最终用户。但这不是你的问题。这是管理层的错，他们没有妥善组织预生产测试。再次强调，不要把责任推到自己身上。你的工作就是保持代码干净，并在合理的时间内完成任务。他们的工作是确保开发人员、测试人员、DevOps、市场人员、产品经理和设计师共同合作，以交付一个具有可接受错误数量的产品。
生产错误不是程序员的错误，但延迟的任务则是。如果你把一个任务拖得太久，你就成为一个无法管理的工作单元。他们根本无法管理你了。你正在做某些事情，试图修复这个错误，说“我在努力，我在努力……”他们如何管理这样的人呢？相反，你应该快速交付，即使这意味着暂时禁用某个功能。
好吧，假设以上都不起作用。代码很干净，文档也可接受，但你无法找出错误，并且他们不接受你的单元测试作为错误不存在的证明。他们也不允许你禁用某个功能，因为它对用户体验至关重要。你有哪些选择？只有一个。
要专业地说：“不，我无法做到这一点，请找其他人。”成为一名专业开发者并不意味着能够解决任何问题，而是意味着诚实。如果你发现无法解决问题，应尽快告知对方。让他们决定如何处理。如果最终因为这个原因被解雇，你仍然是一名专业人士。他们会记住你是一个诚实并且认真对待自己声誉的人。最终，你会获胜。
不要将任务留在你手上。一旦意识到自己不是最适合的人或者根本无法解决问题，通知你的经理。让他来解决问题。实际上，这首先是他的问题。是他雇用了你。他面试了你。他决定给你这个任务。他评估了你的能力和技能。所以现在是他回报的时候了。
你的“不行！”对他来说是非常有价值的反馈。它将帮助他做出下一个重要的管理决策。
另一方面，如果你撒谎只为了给人留下你是一个能够解决任何问题的人的印象，但最终失败了，你不仅会损害自己的声誉，还会影响项目的表现和目标。
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-27 at 05:06
