一天早晨，一切都变了。 该组件因空指针异常而冻结。 仅此而已。 没有日志。 当您需要它们时，它们永远不会存在。 代码或交付方式没有任何变化。 没有明显的过失。 由于其中一份自动报告已失败，因此业务已经发现中断，并且需要估计的修复时间。 对于产品团队的消防员来说，这是一个完美的开始–他们倒了第一杯咖啡。
因此，团队立即采取行动。 半天后–与公司打过多次电话（不是很愉快，请打扰一下，请注意）–建议–可能–在1000左右的几个消息中没有必填字段–顺便提一下，业务流程保证该字段存在。 因此，我们取消了这两个消息并打开了该组件。 瞧，再次坠毁。 这次是因为消息太多，无法处理（请记住在团队对问题进行故障排除时不断出现的消息）。 我不会再打扰您，也不会告诉您解决方案的发送和交付方式。 可以说，为了我的安慰，花了太多的工时。 这导致我写下对此的想法。
我忙于沟通，会议，研讨会，各种要求的创建和设计文档。 我看到了所有这些中的价值。 我确实做到了-尽管多次被指责过，但我没有。 但是，归根结底，没有什么能替代最低限度的街头智慧了。 健康的玩世不恭的态度在设计弹性系统方面大有帮助。 在这种特殊情况下，有几处错误。
1.我们相信来自其他系统的Feed的数据质量。 而且我们不应该拥有。 不会。任何讨论集成模式的书都不会写下来。 这只是一个经验丰富的开发人员不会做的事情，但是一个新的开发人员（尽管像TAC一样敏锐）会逐渐流行起来。 人们信任要求文档以确保某些字段将被填充。 但是，事实是，当不填充字段时，组件无法正常运行。 经验丰富的开发人员会参考需求文档并进行开发，但不会信任需求文档。 他本来会愤世嫉俗的。
2.我们信任该提要的数据量。 而且我们不应该拥有。 同样，这是在文档中写下的内容，因此代码在技术上是正确的。 但是，如果只有开发人员会说：“等等，如果您说您期望的是1000个顶部，那很好，我一次只能拉1000个。 如果还有更多，我将拉第二批。 如果需要，还有更多批次。 但永远不要超过1000。” 我们会好的。 我们不应该从消息队列中提取所有数据-假设数据少于1000，因为它已记录在文档中。 经验丰富的开发人员会对这个文档感到愤世嫉俗。
该组件已修复，一切恢复正常。 没什么大不了的。 这不是第一次发生这样的事情，我愿意打赌这不会是最后一次。 我要提出的观点是，软件生产的业务不像（也许永远不会）像硬件商品的生产线一样。 最不可能享受汽车等生产线的稳定性，可预测性和可重复性。 因此，流程，文档，会议的普及将不会在这项业务中取得成功。
流程很好。 文件很好。 生产率测量工具和代码质量矩阵很棒。 研讨会很棒。 同行评审是必须的。 但是他们不太可能替代一个热爱编码的人，为此而感到自豪，并为此付出更多努力以确保其编码不会失败。 这些人将永远供不应求。 作为一个行业，我们迟早必须找到一种方法来创建，培养和保留这些人。
今天就这样。 别忘了分享！
参考： 编码和犬儒主义。 从我们的JCG合作伙伴 Partho在Tech for Enterprise博客上获得。
翻译自: https://www.javacodegeeks.com/2012/10/coding-and-cynicism.html
1839
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
