如何偷工减料并保持冷静

最新推荐文章于 2024-09-25 11:06:23 发布

danpu0978

最新推荐文章于 2024-09-25 11:06:23 发布

阅读量110

点赞数

文章标签：单元测试 java 人工智能编程语言 python

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

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

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

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

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

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

不要尝试吃意大利面代码；向厨师抱怨，要求他或她做点更好的菜（顺便说一句，我喜欢意大利面）。

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

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

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

编辑：依赖关系的另一个很好的例子可能是在StackOverflow.com或第三方库的用户列表中提出的问题。如果您自己找不到解决方案，而问题不在项目范围内，请向SO提交问题，并将其链接指向源代码（例如，在JavaDoc块中）。

需要更好的文档并等待

所有的依赖关系都已解决，代码看起来很干净，但是您仍然不了解如何解决问题或实现新功能。太复杂了。也许您只是不知道该库的工作方式。否则您以前从未做过这样的事情。无论如何，您不能继续，因为您不了解。为了理解，您将需要大量时间-比您从项目经理或Scrum董事会获得的时间要多得多。你是做什么？

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

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

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

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

重现错误并每天称呼它

现在代码已经干净了，文档已经足够好了，但是无论如何您还是被困了。该怎么办？好吧，我是测试驱动开发的忠实拥护者，所以我的下一个建议是创建一个可以重现该错误的测试。基本上，这是您应该从每张票证开始的内容，无论是错误还是功能。用单元测试捕获错误！通过使用新测试使构建失败来证明该错误存在。

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

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

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

证明Bug的缺席

通常，您根本无法重现错误。那不是因为代码不可测试并且不能在单元测试中使用，而是因为您无法重现错误情况。您知道代码在生产中会崩溃，但是您无法在测试中将其崩溃。最终用户或您的生产日志系统报告的错误堆栈跟踪是不可复制的。这是非常普遍的情况。你是做什么？

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

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

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

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

禁用功能

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

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

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

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