我一直觉得开发人员应该对开发抱有态度，我在博客文章《伟大的软件开发人员的态度》中对此进行了详细介绍。 但是通常在涉及问题时，许多开发人员会找借口。 只要它们是真实的，就不用担心了，但是，如果这确实是一个借口，那么整个团队都应该担心。 我对其中一些人感到内however，但是当我看到全局时，我进行了整改，并了解了人们为什么使用这些借口以及我们将来如何避免这些借口。 我在下面的帖子中详细介绍了一些。
1.在我的机器上工作正常
伙计们，这是开发人员给予的第一借口。 我们经常感到测试人员或客户拥有一台神奇的计算机，该计算机将错误注入我们的代码中。 但这远非事实。
避免这种借口的唯一方法是了解用于开发，测试和生产的环境。 通过了解这些内容，您可能首先要问的是，它是一种什么样的配置/环境，并获得有关该问题的更多详细信息，并检查它是否确实是有效的错误。 避免这种情况的另一种方法是拥有一个持续集成环境，在该环境中，每次签入代码时，都会在一些测试机中编译和部署代码。
图片提供：cheatcc.com
2.您有最新的版本吗？
这是开发人员提供的另一个借口。 没有最新版本来测试或测试错误版本有时可能是此类借口的原因。 但是，并非总是如此。
避免这种情况的唯一方法是建立一个过程，该过程将验证测试人员正在测试的内部版本是否有效且是否最新。 一种方法是进行连续的集成过程，在该过程中，将自动构建代码并将其自动部署到测试计算机上。 这样，过程将确保该版本是最新版本。 确保这一点的另一种方法是验证当前正在测试或部署的内部版本号，如果这与开发人员相匹配，则可以确定这不是问题。
3.必须是配置问题。
如果您告诉我这件事，我会回答：“哦，是的。 可能是配置问题。 那么，您能指出我需要进行哪些确切的配置更改吗？” :)，如果遇到这种情况，您也可能会问类似的问题。 因此，您可以看到，人们需要特定的答案，而不是通用的答案。
避免这种情况的最佳方法是，在单独的配置文件中定义所有与配置相关的参数，并在某些日志文件中写入动态值，以便在出现任何混乱时可以引用它。 通过在运行时以文档化格式进行处理，出错的机会很小，即使问题是由于配置问题引起的，我们也可以很容易地发现这一点。
4.请提出缺陷，我会检查
从我的角度来看，提出缺陷甚至没有确认是否是缺陷，这对我来说就是麻烦。 问题可能出在正在遵循的过程中，或者是开发人员与测试人员之间的协调。 通常，开发人员和测试人员应该联手，以防万一测试人员无法真正深入研究它是否存在缺陷。
避免这种情况的一种方法是在开发人员和测试人员之间保持良好的团队士气和协作。 这样，他们将讨论并尝试找出它是否实际上是缺陷。
5.尝试重新启动计算机：P
这是开发人员的杀手级借口之一。 我也这样做了。 是的，由于某些原因（我以前的项目中主要使用.net），它确实会与Microsoft相关的技术发生，并且在极少数情况下，这种出色且经过深思熟虑，经过科学验证的方法适用于Windows：P，但大多数情况下是假。
避免这种情况的一种方法是再次意识到环境，功能，体系结构和代码设计。 通过了解，我们可以确定它是否实际上是一个问题。
我来检查一下
我讨厌这个借口来自开发人员。 如果作为开发人员，您不确定某个特定原因为何不起作用，则可能是您没有正确理解功能，或者您不了解代码设计
避免这种情况的一种方法是对模块进行心理分析，一旦问题被告知，开发人员需要立即对其进行分析，并找出可能的问题所在。 由于设计不良的代码，不良的代码或对功能或模块的了解不足，因此无法确定可能会出现问题的地方。
7.仅仅5分钟就可以正常工作
哇。 有多甜。 我认为您在其中放了一颗定时炸弹，使其在5分钟后无法正常工作。
避免这种情况的一种方法是知道以下事实：除非是特定时间的代码，否则代码不会随时间变化。 因此，任何其他功能都不会具有此类可变行为。
8.我认为我的代码没有错
如果遇到这种情况，这是我通常不会给出的另一个答案。 我相信没有什么可以称为我的代码，尤其是在团队环境中。 我宁愿说这样的某某模块可能有问题。 这是在试图找人负责，这绝对不符合团队士气的最大利益。
避免这种情况的一种方法是拥抱团队文化，并在不同的模块之间轮换开发人员，以便没有人拥有特定模块的所有权，因此每个人都了解整个代码库。
开发人员还有什么借口，以及将来如何避免？ 请在下面拍出您的评论。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
