开发人员应该反对不必要或有害的功能吗？

在讨论新功能（即非关键/可疑功能）时，开发人员的良好态度是什么？

假设您正在开发某种类似Java的语言，老板说：“我们需要指针，以便开发人员可以直接摆弄对象内存！”

开发人员应该否定这个想法，因为它增加了难以想象的复杂性和安全漏洞，还是应该执行所要求的操作？

这可能不是一个很好的例子，但是在灰色区域显示的内容又如何呢？例如添加破坏工作流程的按钮，或违反程序的内部结构等？

对于普通程序员而言，最佳的“可以做”与“不能做”分配是什么？

编辑：问题不是关于一个坏老板：D

我更感兴趣的是人们如何处理新问题，这些新问题增加了很多数量的问题，而同时又可能微不足道。

一般态度应该是：

1. 是的，我们会做，解决复杂性
2. 也许
3. 不，一般的返工和含义不能证明变更的合理性

一个好的开发者应该怎么做？

最好的方法是召开会议，并安排一个小组的优缺点，然后在此基础上讨论最佳解决方案。如果您有团队，请让他们就解决方案达成一致。一旦团队在某件事上达成共识，经理和“老板”就会倾向于解决方案。

如果您的老板仍然不同意，那么您就可以做的一切：您已经使团队和经理聚在一起，讨论了利弊，尽管老板选择了一个劣等的解决方案。

这样做的关键是作为一个小组来讨论利弊。这样一来，您正在讨论与团队合作的最佳解决方案，同时，在您告诉老板您为什么认为老板决定之后，又在指出您的老板的决定（在他做出决定之前）而没有政治上的强烈反对是错误的。

这是涉及工作政治的温柔情况，但可以友好解决。

如果老板告诉你要做愚蠢的任务，那么你（应该）解释为什么它很愚蠢。

如果他或她不明白这一点，那么您有义务做一些愚蠢的事情。而已。他是老板。在这种情况下，您可以照他/她说的做，或者与他/她的老板交谈或换工作。

您可以告诉老板，尽管在技术上可行，但将花费X的时间和金钱进行分析，设计，重写现有代码，测试，回归测试等工作，然后询问该功能是否值得。有时答案是“是！我们必须有这个！”，有时答案是“不，我想不是”。

如果要求提供的功能违反了应用程序的某些核心原则（例如，将“添加蓝色按钮！”指定和设计为仅根据客户要求仅具有红色按钮的UI），那么我认为可以问“为什么？” 并提到它违背了预先建立的设计。

最后，几乎所有事情都是“可以做的”（从技术的角度来看，在仅蓝色的UI中添加红色按钮可能并不难），更多的是“应该做？”的问题。

为了回答您编辑过的问题，我认为答案应该是＃2，“也许”，有待进一步调查和分析。

您不想回答＃1“是的，无条件”，因为您可能会陷入在给定时间范围内无法交付的事情上。

您不想回答＃3“不，这太麻烦了”，因为那样看来您不合作并且不必要地困难。

从开发人员的角度来看：永远不要告诉任何支付账单的人他们没有想要的东西。相反，您可能会告诉他们，他们无法以这个价格获得它，或者他们不能完全按照最初的想法获得它。

以您的“指针”为例；.NET是托管代码环境，具有指针。对于非托管代码的大量互操作性，它们是至关重要的。但是，对它们的“安全”使用受到严格规范，如果在“不安全”代码中使用，则该代码在运行时需要更高的安全权限。如果您开发的托管语言还需要通过指针进行直接内存访问，则可以提出一种类似的方案，即在可能的情况下在后台编组，使用只读的托管指针，在这种情况下您不能自动编组，并且允许“ “ true”指针仅在代码库的最受信任区域中。

以您的GUI示例为例：如果您知道一项新功能将“破坏”当前代码流，则可以对其进行测试并进行更强大的开发，以回滚该工作流程之前所做的任何工作。您的客户，有时甚至是您的经理，通常对程序的结构一无所知。如果他们想要的东西由于您构造程序的方式而变得困难，那么根据定义，该结构是错误的，因为它不允许您执行客户想要的事情。

在所有情况下，此新功能都可能会超出客户的预期范围而扩大所需的工作范围。反过来，这将需要延长时间表，增加资金和/或减少其他计划的工作。

但是，如果您知道以更简单或更合乎逻辑的方式实现相同基本结果的方法，则可以向客户建议。尽管它们确实存在，但幸运的是，我还没有看到一个客户断然拒绝听取开发人员的意见，尤其是在敏捷环境中，那里有一个“产品负责人”，其唯一的工作就是为开发所需的各种细节负责，例如这些。

如果您花了很多年为大型应用程序编程，并在此过程中进行了认真的思考，您将对功能何时会导致超出其用途的问题产生良好的了解。智慧的另一个说法是，与其他智慧一样，要使那些没有智慧的人看到它的价值可能是一个挑战。

其他张贴者认为，您应该尝试量化将由有问题的功能引起的问题的成本，这是一个好主意，如果可能的话，但通常不是。通常只能估计立即的实施成本。对于较大的功能，即使那样通常也很难。至于未来的成本，您处于困境中。您不确定是否还需要其他功能，或者产品需要维护多长时间。成本通常会远远高于您根据硬事实估算的成本。

您过去表现出的能力越强，您仅需简单地将功能声明为一个坏主意就拥有更多的回旋余地。那只能随着时间的流逝和成功的证明而来。就是说，您应该始终表现出满足请求的渴望，因为这正是您的客户想要的。您应该根据自己的经验表达保留意见，一旦保留，在90％的情况下它就不会成为问题，因为您将开始进行对话，这是问题的根源，即：为什么他们要您添加此功能放在首位？到那时，您可以提供替代方案，或者也许同意，尽管所请求的功能会带来问题，但是仍然有必要。

当然，您也可能错了。软件工程有趣吗？

由于问题很模糊，我将在回答中概括一下。

总是质疑他们，但听他们的推理。有时，人们只是忘记了一项功能的实用性或编程需要花费多长时间。另一方面，我们有时会陷入程序员对高效/没有多余/多余的想法，而我们忘记了我们认为对于项目而言不必要的东西实际上并不适合客户。

如果他们有充分的理由，那么请让他们知道对其进行编程将花费多长时间，以及在实现过程中遇到的所有可能的麻烦，并查看他们是否仍将继续进行。否则，请说明为什么您不认为这是个好主意，然后看看他们的反应是什么。冲洗并重复。

已经说了很多，但是在当前的工作环境中我要强调一件事。我在一家公司工作，该公司是其他公司的承包商，并且应用程序与业务流程有关（相当一部分它们可以促进销售和客户沟通）。

业务流程以及随附的产品可能非常复杂（至少在公司足够大的情况下）。在某种程度上，如果您要建模复杂的事物，那么生成的应用程序将具有相关的复杂性。由于大多数业务人员只看到他们在流程中的部分，因此完整的应用程序/流程所基于的复杂性要比仅一个用户所能看到的复杂得多。

我的观点是，当出现新的业务需求时，它将对业务人员有效，因为它不会使复杂性提高很多，但可能会对整个系统产生更大的影响。我认为这不是反对这种变化的理由。与客户讨论工作量（和费用）是正确的时机。可能并不会阻止客户拥有该功能，但是随着时间的流逝，他们将对这些应用程序有一些了解，并且对“呃，你真贵！”进行了一些讨论。不会那么挑剔。

我不知道您是否处于类似的情况，但是我了解到，利益相关者的情况并不一定像IT系统的开发人员和架构师所面临的那样，具有同样的复杂性。在这种情况下，交流对双方都有帮助。

对不起，这个问题听起来像是一个未成年人，要求父亲的建议。在这种情况下，好的开发人员将需要接受以下诫命：

• 忠于自己。如果您对功能感到不安，请用声音表达您的疑虑。团队只是在等待开幕机会。
• 不要试图用经验丰富的经验法则代替经验。对您来说，每种情况都不同，每种功能都是新的。这是您的老年人没有的一个优点。
• 软件开发不是一门精确的科学，而是永远不会。因此，积累智慧，而不是行为。
• 接受失败。如果团队不同意，请不要重复提出您的疑虑。
• 往正面想。如果这个想法真的是乞求“解决它”，请在列出它的缺陷之前尝试找到它的积极方面。
• 了解如何与人互动。我们的开发人员通常将技术知识置于社交能力之上。技术能力在生活的早期就达到顶峰，但是社交能力可以保持增长直到退休。

我相信可以减少不良要求。但是我也相信，当您尽最大努力解释它们为什么不好并且仍然想要它们时，您就表示同意并做好工作。

例如，有些人想要的需求与应用程序已经完成的工作互斥。如果我这样做，那么将100％保证会破裂。因此，我将需求发回给他们，告诉他们这将破坏我们已经制定的另一条业务规则，他们是否也想更改此规则？通常，提出特定要求的小组无法访问应用程序其余部分可能做什么的全局视图。在大多数情况下，当我向其中的一位发回邮件时，客户已经意识到初始规则更为关键，因此决定他们不希望这样做是不值得的。当他们决定进行更改时，他们在与提出最初要求的人员进行了协商之后才进行更改。

有时，仅问一些澄清问题就会使他们看到问题并不像他们想象的那么简单。有时您想问他们为什么想要一些东西并真正满足推动变革的需求。了解了这一点之后，通常会更容易找到适合您作为开发人员并满足其需求的替代解决方案。如果您能以比原始建议更好地满足他们的需求的方式提出该解决方案，那么您就大大提高了接受更改的机会。

有时，当一项更改会在设计的基本层次上造成严重破坏时，只需给他们提供更改所需的新小时数估计就足以将其关闭。如果您将其与风险评估相结合，指出可能将哪些重要功能引入新的错误中，并告诉他们这将需要3个人花费6周的专心工作，突然间，它不再那么重要了。

但是有时您告诉他们这不是一个好主意，为什么呢，他们仍然说：“太糟糕了，我们需要它。” 您赢了一些而输了一些，有时业务需求确实发生了变化，应用程序必须适应这一点。最终确定该决定后，您就不再需要质疑您在做什么，也没有时间继续做下去了。如果您已记录了反对意见，那么当预算超出预算并引起新的更令人兴奋的错误时，您个人仍然应该处于一个不错的位置。当您建立起对此类事情的正确记录时，他们甚至可能更愿意在下一次听您讲话。

赢得许多讨论的关键（没人会赢得所有讨论）首先要建立一个跟踪记录，以了解您在说什么。接下来，发送一份书面文件，陈述您所关注的问题（许多管理人员面临风险，他们很可能不希望某人后来拥有证明其错误的文件，因此他们会更加注意您的书面内容），最后确保他们了解进行更改的所有成本（不仅是数小时，还包括安全风险，引入新的错误，缺少截止日期等）。变革不是免费的，他们需要了解这一点。下一个关键是像成年人一样，而不是像个抱怨的孩子那样做（“但是我不想使用...，因为我不喜欢它”）。提出一个不这样做的商业案例，您将在回退糟糕的需求方面走得更远。

如果我没看错，真正的问题是未知的复杂性。最初，我读到您的问题是：“我看到极有可能出现过度复杂的风险，但老板没有。”但是您是说老板不是问题，所以我认为您不确定会有哪些风险增加了无法接受的复杂性。

在这种情况下，我建议使用某种风险缓解策略。您正在考虑将WCF / Web服务添加到您的API中的图像，这可能真是棒极了，或者很复杂，却没有回报：

• 在分支上添加功能。如果可行，请合并它。如果变成老鼠的巢，将其杀死。
• 启动一个新的一页项目并进行概念验证。如果您不能在短时间内完成概念验证，请删除它。如果概念验证有效，请将其放大并与您的产品集成
• 搜寻网络以吸引那些渴望使用该功能或​​技术的人们。在发生大量困扰的情况下，技术可能会带来一些过于复杂的实际风险。Java Beans和COM +可能已经很老了，但是这些功能的好例子确实增加了复杂性，并且在等式的优势方面可能已经实现，也可能没有实现

争论号 讨论可能是。但应将其视为规范的补充，并优先考虑其他功能。如果您知道该请求将增加不合理的时间和复杂的实施时间，则请事先声明。不反对提出请求，只是解释您认为将要执行的内容。

它在很大程度上取决于请求。指针的实现足够大，可以影响整个项目，因此如果可以选择，则应权衡其优点。

实现一个破坏流程的按钮。如果可以通过按钮是可选的方式来布局表单，则可能不会有什么大不了的。我实际上已经做了这件事。我添加了按钮，但在手动操作之前收集了足够的信息，使按钮成为可选的。期望它在那里的用户使用了它，而意识到它只是多余的用户则没有。

一切都与平衡和知道何时进行战斗有关。无论如何，有些事情比不包括它的社会方面更容易实现。

我看到的问题是您使用了争论一词。

您必须提出设计问题及其背后的原因，但要警惕，因为程序员倾向于对自己所担任的职位持防御态度，并仅出于争论的目的而争论要点（有时）。我必须阻止自己争论很多，而且我并不总是成功。另外，随着年龄的增长，我发现自己犯错的频率比以前更频繁-更糟糕的是，我不知道自己以前犯错的频率:)

如果您有明确规定的要求（语言必须安全，我们需要访问旧式例程的指针），那么您可以介绍这两个要求如何冲突并询问哪个更重要。有了需求及其背后的原因后，您甚至可以提出一种完全不同的解决方案来支持这两个需求（JNI--kinda）。

如果没有，那么也许是时候编纂它们的好时机！

1. 意识到自己一无所知，无所不能。

2. 如果您确定这是个坏主意，请说出什么不好。

3. 如果他们试图将其强加给您，请说-需要更多时间进行分析，或者需要更多时间，或者说我们没有找到解决此问题的好方法。

4. 如果他们仍然坚持实施这个坏主意，请从他们那里得到您已反对该主意的建议，包括您的理由。您甚至可以发送一封电子邮件，将讨论的摘要和副本发送给您的经理。以后可以保存您的**。

在理想的情况下，您将有一名首席开发人员在技术方面做出最终决定，并有一名业务主管在业务方面做出最终决定。这将回答两个主要问题：

1）什么？客户想要什么？

2）如何？我们如何从技术角度实现这一目标。

客户想要的是最终的决策者，因为他们是支付账单的人

作为开发人员，您不必在乎要实施哪些要求。

但是，您应该解释一些不现实的事情以及是否有更好的方法。

有时是实际的客户要求（来自客户内部政治）。然后它就绝望了，必须完成（但是管理层还应该考虑是否继续进行该项目，或者是否应该重新谈判价格。）

对我来说，这几乎是每天的任务，实际上我很高兴。

如果您有更改要对某些要求是否应作为应用程序的一部分发表意见，则非技术人员会希望您填写自己的技术知识（例如，“使用指针会使应用程序不稳定”或“使用X的GET参数存在安全风险”）。技术人员也希望您对他们可能没有想到的某些优势或劣势提出反馈。

当然，当每个人都想要功能X并最终说“可能不好”时，这很严厉，但最终，每个人​​都在尝试制作一个安全，健壮和稳定的应用程序（可维护，灵活等）。 ），每个声音都应发挥作用。

回答您的问题，这不是开发人员（即开发人员）工作的一部分，而是提供质量和团队合作的“额外”工具。

如果您能够理解这样做的弊端（复杂性，缺乏可用性等），那么尽您所能来解释它就符合每个人的最大利益。通常，非开发人员不了解添加新功能的问题。对他们而言，这很容易，因为他们不必做任何事情，甚至都无需考虑。

但是，如果确定将要添加新功能的功能，那么您应该尽力而为。这是一个挑战。

而且，如果新功能太愚蠢或工作环境太糟糕，那么该找另一份工作了。