我们的客户有“没有不必要的代码”政策。他们分配给我的项目的人认为这包括：
他们告诉我，我可以有一个用于“验证算法”的版本，但必须从客户提交的文件中删除。我尝试解释我无法验证与我提交的版本不同的版本，但他们似乎没有得到它。跨平台的东西很重要，因为我们通常同时开始硬件和软件设计，早期开发必须使用不同的硬件集进行测试/调试。
目前尚不清楚谁拥有您的代码（您的雇主或客户），或者您的客户是否不愿意为此代码付费或只是不愿意随它一起提供。例如，如果您的客户认为他们不关心跨平台，那么他们不愿意为可能只会在未来使他们受益或可能只会使您的其他客户受益的东西付费是完全正确的。
此外，如果您的客户正在为嵌入式平台开发，那么 ROM 和 RAM 的每个字节都很重要，而且他们再次要求您消除不必要的代码是正确的。
那么，如何在满足客户需求的同时维护一个单一、统一、无差异的代码库呢？专精！
我有一位同事创立了一家公司，其唯一业务是 USB 软件堆栈。他们有令人难以置信的跨平台问题、配置等等。他们对这个问题的解决方案是拥有一个单一的代码库，然后他们会自动为每个客户专门定制它。自动专业化包括删除特定平台上被视为“不必要”的代码之类的事情。在不了解您的问题、您的业务或您的其他客户的更多信息的情况下，这就是我会为您推荐的路径。
这是一个艰难的决定。我已经完成的大部分建议已经完成，并发表了评论。但我确实还有一个。
在评论中，您提到“当真正的问题发生时，他们通常会忘记我们的设计反对意见，并将其归咎于我们。” 这对我说，你处于一个没有胜利的境地。
在不知道您与该客户的关系的情况下，除了其持续时间（和明显的好斗性）之外，我唯一的建议是编写经过验证的设计异议文档。这是更多的工作，但是当他们否决你，然后因为这个问题而责怪你时，这是一个 CYA。如果他们已经支付了 T&M 费用来解决现场发现的问题，这可能就不那么重要了，但是如果他们希望您免费解决这些问题，这可以用作谈判的筹码。
几轮修复对他们的伤害和对你的伤害一样大，他们可能会转身开始允许一些诊断（如果没有别的）。
仔细解释如果没有诊断代码，支持请求将成倍延长，并且您不能对支持请求的超长周转时间负责，并且您希望根据解决给定问题所需的时间长度动态支付，客户是否应该维护他们当前的软件策略。
如果他们仍然坚持自己的观点，请与客户一起去。在他们至少被烧过一次之前，他们不会觉得有必要改变他们的方式。
编辑：我假设单元测试等不包含在您的最终交付成果中，因为那会很愚蠢。也许客户认为是这样的。
编写一个简单的脚本，从您的实际源代码生成要审查的源文件。