与开发人员打交道，不断忽略其工作中的极端情况

我猜想我团队中的一位开发人员有一个有趣的，相当普遍的问题。这个家伙是一个伟大的开发人员，工作迅速且富有成效，产生相当高质量的代码。好工程师 但是他有一个问题-他经常无法在代码中解决边缘情况。

我们多次和他谈过这件事，他正在努力，但我想他只是不这么认为。所以最终发生的事情是，QA会发现他的代码有很多问题，然后一次又一次地将其返回给开发人员，最终导致错过最后期限，并且团队中的每个人都不满意。

我不知道该如何对待他以及如何帮助他克服这个问题。也许有更多经验的人可以建议？

要求他为其代码编写自动化的单元测试。编写单元测试会迫使人们仔细思考一些案例。

一些细节：

1. 为了确保他不会被选拔，应该为整个团队建立这种做法。要求所有人针对新代码或他们修改的代码编写自动化的单元测试。
2. 要求单元测试名称必须描述所测试的情况。
3. 在代码审查中全面介绍自动化的单元测试。让审稿人寻找遗漏的测试用例（即他常年遗漏的那些边缘案例）。在他的团队对遗漏的边缘案例提供了一些反馈之后，他可能会学会在审阅之前考虑这些案例。
4. 对整个团队强制执行此规则：如果QA发现错误，则负责开发的人员应归功于自动测试，该测试确认了故障，然后证明他们已解决了问题。（在他们做任何其他工作之前）

给他一张清单，例如

• 空输入
• 输入范围很大
• 输入范围极小
• 组合
• 输入违反假设不变性（例如，如果x = y）

质量检查人员可以帮助设计清单

将清单提供给所有开发人员，而不仅仅是这份清单。

好工程师

好的。

但是他有一个问题-他经常无法在代码中解决边缘情况。

优秀的工程师所无法比拟的品质。

注意边缘情况是人中是否存在的一个特征。它与成为工程师或程序员无关。这一特征的发展受文化背景，生活环境，童年事件和生活经历的影响。然后，将态度简单地应用于个人所做的任何工作。

您需要的是找出您的人是否属于这种尚未发展到某种意义上的人（也许还没有）。他也很可能出于某种原因不在乎。您需要分析整个情况，他的工作是否愉快。如果不是这样，也许您应该先做些帮助他的事情。

如果他的工作还不错，但还没有经历过边缘案件的危险，那么您可以开始对他进行教育。如果他认真对待，他可能会随着时间的推移改变自己的方式。尽管我对此表示怀疑，但您仍然可以尝试一下。

但是，如果他变成那种在边缘情况下不擅长的人，那么您可能别无选择，只能将他从团队中删除。该特性对于实际编程至关重要。可悲的是，没有它，即使一个伟大的人也无法创造出出色的工作。

您能否在此过程的早期进行代码审查或设计审查？

教他编程测试优先。与他配对。您将编写测试用例，他将编写代码以通过测试。

是否可以让QA尽早参与功能开发，从而帮助他提供一开始就要涵盖的边缘案例列表？尽管有些人可能不希望开发人员涵盖所有内容，但如果开发人员倾向于错过测试人员最初可能会抓住的那些边界情况，则这可能是解决此问题的一种方法。

我在这里遇到的另一个想法是他如何看待这个问题。他真的为这种模式感到烦恼并tick之以鼻吗？还是他只是认为这是正常现象，而不是让他担心解决的问题？当然，这确实需要很大的信任，并且要让他保持开放的态度，但是我认为，如果您能从他的角度看到事情，这里会有一定程度的同理心可能会有所帮助。

边缘案例的数量是无限的，将它们全部覆盖都是不可行的。如果有人这样做#define TRUE FALSE怎么办？它增加了边缘情况，您也会检查它们吗？

另外，我不会考虑对私有类或内部函数的每个函数进行安全验证。

我为必须非常扎实和稳定的代码选择的方法是：

if(conditions_met)
{
DoStuff();
}
else
{
CrashAppAndDumpMemory();
}

这样，您就可以在质量检查中获得可靠的应用程序转储，并且在发布之前，该应用程序是可靠且安全的。

解决错误是不好的。好的，如果文件句柄为null并返回null，则可以保存一个函数，但是在大多数情况下，某处存在设计错误，而应用程序崩溃是强制您查找原因的更好方法。大多数边缘情况只是通过隐藏问题来掩盖错误，例如-按钮停止工作。崩溃告诉您有关产品的某些假设是错误的，因此您必须修改导致崩溃的逻辑。

如果是极端情况，是否甚至需要考虑？如果边缘案例很重要，则需要将边缘案例输入到需求/功能/用户案例中。

如果边缘盒被认为是一件工作的一部分，并且要求将设备放在适当的位置，那么它们应该是工作项目的一部分，并且根据定义，直到处理边缘盒的机制得以完成，工作项目才是完整的到位。

这给您作为团队负责人在工作后讨论期间完成工作后需要检查的东西，并且为开发人员在完成工作时需要检查的东西提供了检查。

赶上前沿案例是为什么存在质量检查的原因。程序员有责任及时进行工作。将所有时间都花在寻找极端情况上是非常低效的。如果您有一个相当快的迭代周期，那么这应该完全没有问题。边缘案例的数量接近无限。如果“核心”案件有问题，那么我会有点担心。正如开发人员是开发专家一样，测试人员也应该是测试专家。当测试人员发现问题时，他们将其发送回开发。开发人员解决了该问题。问题解决了。开发人员追踪所有极端情况的时间比迭代测试周期所需的时间长得多。还要注意，当我谈论测试时，我并不是指白盒单元测试，而是严格的黑盒测试。

我认为测试驱动的开发可以解救这种情况之一，因为它有助于从边缘情况和任何可能破坏代码的方面进行思考。