如何偷工减料并保持冷静

您已分配任务，但您不喜欢它。 您根本没有心情。 您不知道如何解决该死的错误。 您不知道该模块如何设计，也不知道它是如何工作的。 但是您必须解决此问题，该问题是由不知道此软件如何工作的人 告的。 您会感到沮丧和责备两年前被解雇的愚蠢的项目经理和程序员。 您花费数小时只是为了了解代码的工作原理。 然后还要花更多的时间尝试修复它。 最后，您错过了最后期限， 所有人都怪您 。 去过也做过

但是，有另一种方法可以从这种情况下专业退出。 这些是我推荐给在teamed.io项目中与我一起编码的同事的一些技巧。 简而言之，我将解释如何捷径并保持专业水准，1）保护自己的神经，2）优化项目的费用，以及3）提高源代码的质量。

以下是按优先顺序排列的选项列表。 我建议您从列表中的第一个开始，然后在必要时继续进行。

创建依赖关系，责备他们，然后等待

这是第一个也是最可取的选择。 如果您不知道如何解决问题或如何实现新功能，那是项目的错，而不是您。 即使您无法弄清楚，因为您对Ruby一无所知，他们也雇用您来修复Ruby on Rails代码库中的错误-这是他们的错。 当您对Ruby一无所知时，为什么他们雇用您

所以要积极； 不要怪自己。 如果您不知道该死的代码是如何工作的，那是代码的错，不是您。 好的代码易于理解和维护。

你该怎么做创建依赖关系-新的bug抱怨设计不清楚，缺少单元测试，缺少必要的类等。 具有创造力和进攻性-当然，以建设性和专业性的方式。 不要个人。 无论是谁煮意大利面，您都不会对他或她本人不利。 您只想要另一道菜，仅此而已。

一旦 告了这些依赖关系，请在主故障单中说明直到所有问题都解决后才能继续。 您将合法地停止工作，其他人将改善您所需的代码。 稍后，当所有的依赖关系都解决并且代码看起来更好时，请尝试重新回到它。 如果仍然出现问题，请创建新的依赖项。 继续这样做，直到您前面的代码干净并且易于修复。

不要成为英雄-不要急于修复您继承的错误代码。 像开发人员一样思考，而不是黑客 。 请记住，作为一名训练有素的工程师，您的首要也是最重要的职责是帮助项目揭示可维护性问题。 谁来修复它们以及项目经理的责任是什么。 你的工作是揭示而不是隐藏。 通过成为英雄并尝试在单个任务的范围内解决所有问题，您就不会对项目有所帮助，而是在掩盖问题。

需要更好的文档并等待

再说一次，积极思考，不要怪自己。 如果软件对于一个陌生人来说还不够清晰，那是“他们”的错，而不是您的错。 他们以难以消化和修改的方式创建了该软件。 但是代码是干净的； 它不再是意大利面了。 这是一个煮熟的龙虾，但是你不知道怎么吃龙虾！ 您从来没有吃过它。

厨师做得很好。 他煮得很好，但餐厅没有给您任何有关如何食用这种精致菜肴的指示。 你是做什么

您需要一本手册。 您要求提供文档。 正确设计和编写的源代码必须正确记录在案。 一旦发现尚不清楚的地方，请创建新的依赖项，以寻求有关代码某些方面的更好文档。

同样，不要成为英雄，而是要自己理解一切。 当然，您是一个聪明的人，但是该项目不需要一个聪明的人。 该项目需要易于维护的可维护代码，即使那些不如您自己的人也容易修改。 因此，对您的项目有帮助吗：揭示文档问题，然后请某人为您修复它。 不只是为了您，也为了所有人。 整个团队将从此请求中受益。 文档固定后，您将继续执行任务，每个人都将获得比以前更好的源代码。 双赢，不是吗

重现错误并每天称呼它

这可能很难实现，尤其是当您尝试修复或修改的软件是由对单元测试一无所知的白痴编写的时。 有很多技术可以帮助您找到使此类软件更具可测试性的方法。 我强烈建议您阅读Michael Feathers 撰写的《有效使用旧版代码》 。 有许多不同的模式，其中大多数都起作用。

一旦设法重现该错误并且构建失败，就在此处停止。 一件一件工作就足够了。 跳过测试（例如，使用JUnit 4中的批注）并提交更改。 然后将文档添加到刚创建的单元测试中，最好以的形式。 向那里说明您设法重现了该问题，但是没有足够的时间来解决它。 或者，也许您只是不知道如何解决它。 说实话，并提供所有可能的细节。

我相信，在大多数情况下，通过单元测试捕获错误的成功率超过80％。 其余的方法更简单：只需修复代码并通过测试即可。 将此工作留给其他人。

证明Bug的缺席

我认为最好的选择是创建一个测试，以证明代码按预期工作。 测试不会失败，并且构建将保持干净。 您将其提交到存储库中，并… 告问题已解决。 您会说，所 告的错误在现实生活中并不存在。 您将声明没有错误-“我们的软件可以正常工作； 这就是证明：请参阅我的新单元测试。”

他们会相信你吗我不这么认为，但他们别无选择。 他们再也不能推你了。 您已经做了一些工作–创建了一个新的测试，证明一切都很好。 门票将关闭，项目将继续进行。

如果以后在生产中出现相同的问题，将 告一个新的错误。 它将链接到您的票证。 您的经验将帮助某人进一步调查该错误。 也许那个家伙也不会通过测试来发现错误，并且还会创建一个新的，成功的和“无用的”测试。 这可能会一次又一次地发生。 最终，这种累积的小组经验将帮助最后一个人发现并修复该错误。

因此，新的通过测试是对单元测试无法捕获的错误的良好响应。

禁用功能

有时，单元测试技术不起作用，主要是因为错误太重要而无法忽略。 当您向他们展示证明该错误不存在的单元测试时，他们将与您不同意。 他们会告诉您“当我们的用户尝试下载PDF时，他们会得到空白页。” 他们还会说，他们并不真的在乎您的流血单元测试。 他们只关心应该可下载的PDF文档。 因此，使用单元测试的技巧将不起作用。 你是做什么

它取决于许多因素，而这些因素大多数都不是技术因素。 他们是政治的，组织的，管理的， 会的，随便你怎么说。 但是，在大多数情况下，我建议您禁用该有毒功能，发布新版本并关闭票证。

您将把问题从肩膀上解脱出来，每个人都会感到满意。 好吧，除了那个可怜的最终用户。 但这不是你的问题。 这是管理的错误，没有正确组织生产前的测试。 同样，不要怪自己。 您的工作是保持代码干净，并在合理的时间内完成票证。 他们的工作是确保开发人员，测试人员，DevOps，营销人员，产品经理和设计人员共同努力，以可接受的错误数量交付产品。

生产错误不是程序员的错误，尽管工单是延迟的。 如果您在手中持有票证的时间过长，您将成为无法管理的工作单元。 他们根本无法管理您了。 您正在做一些事情，试图修复该错误，并说：“我正在尝试，我正在尝试……”他们如何管理这样的人而是，您应该快速交付，即使这是以暂时禁用的功能为代价的。

说不

要专业，说：“不，我不能这样做； 找别人。” 成为专业开发人员并不意味着能够解决任何问题。 相反，这意味着诚实。 如果发现无法解决问题，请尽快说出来。 让他们决定要做什么。 如果他们最终决定因此而解雇您，您将保持专业水平。 他们会记得您是一个诚实的人，并认真对待他的声誉。 最后，您将获胜。

不要将任务掌握在手中。 当您意识到自己不是最佳人选或无法解决问题时，请立即通知您的经理。 成为他的问题。 实际上，这首先是他的问题。 他雇用了你。 他采访了你。 他决定给你完成这项任务。 他估计了您的能力和技能。 因此，这是投资回收期。

您的“不！” 对他来说将是非常有价值的反馈。 这将帮助他做出下一个重要的管理决策。

另一方面，如果您撒谎只是给人以印象，您就是一个可以解决任何问题却最终失败的人，这不仅会损害您的声誉，而且会损害项目的绩效和目标。

翻译自: https://www.javacodegeeks.com/2015/02/cut-corners-stay-cool.html

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览91758 人正在系统学习中 相关资源：减压孔板计算软件v1.1免费绿色版-其它代码类资源-CSDN文库