有时，我们为了让应用程序中能更方便的满足用户需要时，会在程序中添加一些可选的功能特性，如果用户的情况需要特定的功能，我们可以在程序中启用这些特性。我们的意图是好的，但是这些行为实际上会导致更多的问题，因为我们邀请用户通过在用户体验中添加额外的步骤来猜测他们的选择。
开源最著名的方面之一是允许开发人员通过添加一个可能不适合所有人的可选特性来满足用户的需求，但是允许一小部分用户以特定的方式参与项目。虽然这似乎是一个很好的想法，以满足个人的需要，有几个缺点，使某件事的选择。
它增加开发人员的工作
创建额外的选项意味着前端和后端团队都需要做更多的工作。这些特性为每个设置添加了额外的代码、测试和文档，并且各种状态会更改UI。在开发过程的每个步骤中添加选项都会对您造成伤害。
它给用户带来了选择的负担
当我们通过包含选项来解决问题时，我们迫使用户考虑这个功能，并考虑它的用途和缺点，从而给他们带来了控制如何使用应用程序的负担。用户犹豫不决，必须决定是否应该启用此功能。毕竟，如果一个选项显著增强了用户体验，那么它不是已经被自动集成了吗?
它使未来的功能更难实现
另外还有其他选择的长期影响。仅仅一个额外的选项就可以导致两个路径中的一个，这可能会影响应用程序的其他部分。因此，每当我们添加一个选项时，应用程序的状态数就会翻倍。这是指数式增长，加起来很快，使得错误诊断更加困难。多个选项可能会导致创建我们不知道的状态，所以用户很难理解应用程序应该如何运行，因为他们不知道错误是否由选项引起。如果是一个选项导致了错误，问题出在哪个选项上?
我们如何避免添加选项
那么，您如何知道一个特性是否应该是可选的呢?在GitLab，我们发布了第一个迭代，并根据用户反馈继续发布。我们预期的一些特性可能永远不会推出，因为用户不会请求它们。迭代允许我们减少开发范围，避免包含不受欢迎或不可用的特性。
当用户需要新东西时，尝试创建一个大多数人都能接受的解决方案。依靠您的开发和运营团队提供反馈，并要求他们与最终用户建立联系。与用户进行用户体验研究还有助于识别痛点和需求。
团队不断受到开发能力的限制，向应用程序添加选项可能会占用以前的时间和精力。我们建议在没有选项的情况下发布您的应用程序，并等待人们是否提出请求或为其提出功能建议。最后，我们的角色是解决用户的问题，而我们的目标是识别挑战的根本原因，并以一种不需要选择的方式修复它。
閱讀更多 程序你好 的文章
