这些迹象表明开发人员不好吗？[关闭]

我曾经指责客户更改规范会导致代码腐烂，而没有意识到业务模型确实会发生变化，而我的工作就是以适应性方式进行开发。现在，我认为这表明开发人员表现不佳（我已更改！）。

但是现在我自己身上看到了其他“ whi”。最近几次，我发现自己说“这就像试图将一个方形的钉子插入一个圆孔中”，而且我发现自己将客户的犹豫不决归咎于项目没有进展。

有迹象表明我应该寻找可以改变态度的地方吗？客户总是对的，还是有时候我感到沮丧？

我不会说你是不好的开发人员。意识到这些问题已经使您超越了这个定义。

需求变更。那是给定的。一个好的开发人员需要考虑到这一点。许多现代编程技术都可以帮助解决这一问题。

遵守原始规范是不现实的。一直在改变需求也是不现实的。

客户肯定不是总是对的。不过，这比我们希望他/她更经常的是“正确的”（例如，如果他还没有完全离开，则尝试容纳他）。但是，当您看到他将项目推向错误的方向时，请尝试倡导您认为正确的事情。

这些事情没有硬性规定，即使是优秀且经验丰富的开发人员也未能实现完美的“禅”。唯一错误的方法是不尝试在这些方面进行改进。

在某些情况下，它是客户端。但这也是你的问题

在某些情况下是开发人员，在某些情况下是客户。但是，通常它们都是您的问题，因此责备自己的态度往往会更成功，因为这会错误地解决问题，而不是无助的指责。因此，您经常会在经验丰富的开发人员中找到它。

恕我直言，一种更好的态度是无怨无悔地看待它：“这是客户，我有糟糕的代码，因为他总是更改要求，这是客户的错”，然后变成“这位客户正在弄清楚自己想要的东西，因此反馈，快速的原型设计和灵活性更加出色比完整性，健壮性和速度更重要”。

一种禅意：不要判断，只是看它是什么样。

首先，客户直到看到客户才知道他们想要什么。这是敏捷范例在客户大量参与下进行小迭代的吸引力的一部分。其次，当代码完成时，不要指望产品是“完成的”。

Microsoft使用一种名为“ Watson”的产品（Windows崩溃时会发送反馈消息），以便将问题直接追溯到客户端。可追溯性是将问题追溯到遇到问题的用户的好方法。您可以通过询问获得可追溯性。或者，如果您有资源，请将功能集成到产品中。关键是跟踪问题/改进，以便可以解决它们。

最后，确保客户的善变。在这种情况下，我尝试着眼于冰山秘密。

不断变化的需求是生活中艰难的事实；但是代码腐烂不是由那引起的。

当您的某些代码部分不经常使用时，就会发生代码腐烂。因此，当您进行一些“不会影响其他任何事情”的更改时，可能会引入错误。换句话说，看不到日光的代码会缓慢分解，并且您无法确定停止工作的时间。

是的，这是您的错，而不是您的用户。

真正的解决方案？经常测试所有代码。当然，最好的方法是进行覆盖范围广的自动化测试。

客户优柔寡断可能是一个大问题，如果您不是负责管理客户关系的人，那么可能很难解决。您可以与与客户打交道的人交谈，并冷静地解释，只有在客户做出决定之前，进度才能实现。如果你是负责客户关系的，你必须告诉客户，他们需要做出决定之前，该项目可以继续进行。可能不是您的态度需要大修，只需沉思一分钟即可平静下来。;）

哈维尔指出，不断变化的需求是生活中艰难的事实。这些情况令我感到沮丧，因为我经常发现自己在开发人员必须做出决定的产品上工作。我的观点曾经是“为什么管理人员不能与客户一起解决这个问题？”，或者“如果客户不知道他们想要什么，为什么我们要开始这个项目？”在开发后期”。

一个简单的事实：这将永远发生，不仅在编程/软件开发中，而且在生活的各个方面。如果人们从不改变主意，从不适应，从不应对变化，那么世界将简直是一个无聊而又与众不同的地方。人们倾向于看待自己得到的东西，并加以改进。您是否对代码执行相同的操作？如果我对自己不满意的代码块（效率低下，混乱不堪），将对其进行改进。（操作系统是否向我抱怨？...有时，如果我使用的是某些未命名的操作系统，但通常不会）

作为程序员，我们需要抓住机会来改进事情，而不要为之沮丧或烦恼。借此机会与人们交谈，改善自己的风格，提高职业道德，持开放态度对待事物，推动自己变得比昨天更好。事业前进，不要太容易安定。

我了解并非所有人都会同意这个答案，但是我认为重要的是，这个问题的答案应涵盖更广阔的视野。

与客户互动时，您不是在编程；您正在学习和教学。

让客户了解情况并教育他们有关该过程的信息。变化将发生。让他们知道您将尝试实现它们，但这会花费更多。让他们决定。

即使他们提出的问题本质上是技术性的，也不要进入技术细节。您之所以受诱惑是因为您会感到有点防御，并且会想挑战/继续前进。不要做 他们不在乎细节，并且会在45秒后停止收听。

如果您没有提前告诉他们，不要指望他们了解行业标准和最佳实践，或以其他任何借口做自己的工作。当我直到最后才看到费用时才讨厌它，只是让销售人员告诉我这是行业标准。我不应该知道这一点。我的回答是：“也让我觉得自己像个笨蛋吗？”

与客户在一起时，要比房间里的任何人或其他任何事物都更加注意他们。驯养的狗是天才。特别是如果你有食物。

这是糟糕的需求管理或糟糕的分析。您的业​​务分析师（如果有）或满足要求的任何人都需要与客户坐在一起，并尝试获得所有要求，即使是客户可能没有想到的要求。客户通常并不了解他们想要的一切，出色的业务分析师将帮助他们解决所有问题。

这就是为什么您应该始终获得业务需求文档设置并在任何应用程序超出原型设计/研究阶段之前注销的原因。

现在，该文档实际上是最终文档的想法是错误的，但这应该可以帮助您更好地了解客户的实际需求。只要您在编写代码时就考虑到可维护性，就可以将问题降至最低。

而且，如果您需要借口再使用，则可以将BRD的任何延迟归咎于客户端已签名，不包括此类功能等。

（当然，这只是万一需要的借口。您应该始终计划让他们更改某些内容）

用艾默生的话说：“愚蠢的一致性是小头脑的妖精……”最常被忽视的词是愚蠢的。一致性在某些情况下是不可协商的，但是它通常可以替代批判性思维和分析。

一方面，许多开发模型是专门为帮助您描述的环境而设计的；因此，如果您发现自己必须违反模型，则可能是您一开始就没有正确实施模型，或者模型错误。

但是，另一方面，如果您有合理的理由支持违反规则，并且可以证明您的流氓方法产生更干净，更可维护的代码，那么您不必害怕采取明智的做法。