tol*_*lak 17 performance reliability robustness
我们的产品是分布式系统.我工作的模块相当新,非常严格,经过严格测试.它们是根据最近的最佳实践开发的.其他模块可以视为传统软件.
虽然我对我负责的模块中发生的所有事情保持警惕,但我仍然面临着处理从其他模块发送给我的不良数据的压力.从本质上讲,我是一个"快速失败"原则的开发人员,因此,当问题出现时,我通常能够消除模块中出错的可能性.这不仅仅是责备,只是在错误的地方浪费精力去追逐虫子.
但我不断反对的论点是:"我们不能让这些东西在生产中失败,客户希望这个能够发挥作用,为什么你不解决这个问题".这将是一个强大的论据:你接受的是自由的,你发送的是保守的.
我还应该注意到,这些主要是间歇性的问题.我们在集成测试中看到它们,但它们很难重现.涉及时间和并发.
我很难在这两个原则之间取得平衡.部分原因是我担心,如果我开始允许和传播特殊数据,我会引起麻烦,我对系统的信心也不会那么高.但即使其他模块向我发送错误的数据,我也不能反对保持系统正常工作.其他模块没有得到修复的原因是它们太复杂和脆弱,而我的仍然显得清晰和安全.但是,如果我不抵抗压力,我的模块将慢慢地背负着我一直拒绝的同样问题.
我应该说系统没有在生产中"崩溃",但是我的模块可能只是向操作员显示错误并要求他们联系支持人员.崩溃将是一个大问题,但如果我清楚地报告错误,那么这不是正确的做法吗？我怀疑我的同行只是不希望客户看到任何问题,期间.但是我的模块拒绝了我们产品中其他模块的数据,而不是客户输入.所以在我看来,我们只是没有解决问题.
那么,我是否需要更务实或坚持自己的立场？
感谢大家。引发这个问题的案例结局很好，部分归功于我从上述答案中获得的见解。
我最初的反应是坚持快速失败，但我对此进行了更多思考，并得出结论：我的模块的作用之一是为系统的其余部分提供稳定的锚点。这并不一定意味着接受不良数据，而是暴露问题、隔离问题并以透明的方式处理它们，直到找到解决方案。
我计划为此案例添加一个新的处理程序和代码路径，它将正确执行，就像它是以前未记录的特殊用例一样。
我们进行了讨论，我重申需要解决边界问题，但也愿意提供帮助。我向对方概述了我的计划，因为我怀疑我的立场被视为过于迂腐，并且解决方案被认为是我只需关闭对无害数据的虚假验证，即使它是不正确的。但实际上，我的工作方式很大程度上是数据驱动的，所以我解释了为什么它必须是正确的，行为是如何由它驱动的，以及在适应这些数据时我将如何实现一个特殊的代码路径。
我认为这增强了我的立场，并导致了对另一方不愿修复数据的更彻底的讨论。事实证明，这更多的是对处理容易出错的遗留系统的厌倦，而不是实际的障碍。有一个相对简单的解决方案，只是做出改变是可怕的，这是一种相当根深蒂固的心态。
但在提出了所有挑战和可能的解决方案后，我们最终同意修复数据，到目前为止似乎已经解决了我们的问题。我们的集成测试现在一致通过，但我们还添加了日志记录并将继续监视它。
总而言之，我认为对我来说，这两个原则的综合是，快速失败对于解决问题至关重要。但一旦它们浮出水面，稳健性就意味着提供一条透明的路径，以不损害系统的方式继续运行。我能够提供这一点，并通过这样做赢得了对方的一些善意，并最终修复了数据。
再次感谢所有回复的人。我太新了，无法评价评论，但我确实很欣赏所提出的所有观点。