开发和运营中的同理心

你通读了一遍代码。你又读了一遍，确保你理解了它的作用。你的左眼开始抽搐。你又读了第三遍代码。

“写这篇文章的人到底是怎么了？”

我讨厌自己经常有这种反应。这是一种很难重置的默认行为——“立刻就烦死了，就好像我遇到的那些代码的开发者或工程师在埋地雷一样。”

批评前人很容易。他们通常不会在身边为自己辩护，也不会提供背景信息。这是一种常见（但糟糕）的自我抬头和炫耀能力的假象。“看看我知道多少，而他们不知道！”

冷静下来、感同身受、思考问题要困难得多。最初的反应是“WTF？！”完全正常（你会感受到你想要的感受），但陷入沮丧而无法继续前进对你的前辈来说很不公平，也会让你错失学习的机会。

怎么做？ vs. 为什么？

问题“如何”得到解决/临时解决/被搁置通常是造成这些挫折的根源，但下一步是思考解决方案的“原因”，这通常是有用信息的来源。

代码可能很蠢，但通常都有原因。比如：

这并不排除懒惰或恶意，但它们非常罕见，不应成为默认假设。当我们遇到看起来愚蠢的代码和配置时，我们需要尊重编写它们的人所面临的限制和环境。

注意：这个人可能真的是个白痴，这确实是一个难以克服的限制。你会怎么解决这个问题？对他们大喊“聪明点！”？

仔细思考并了解导致愚蠢行为的“原因”将有助于你理解当前问题的背景。你不仅会了解到技术陷阱，还会了解到文化陷阱。代码中出现的很多愚蠢行为与编写者的技术能力无关，而与他们的经理或整个公司息息相关。

过去的你，做过多少傻事，伤害了未来的你？你有多少次看着一年前做的东西，心想：“我当时到底想了什么？”

就像任何技能一样，如果你对自己过去编写的一些代码和配置不感到羞愧，那么你就是：1.) 一个自负的怪物；2.) 不会进步。明白这一点，请给自己和前辈一些宽容。

当 DevOps 从业者谈论建立文化时，他们讨论的一大要素就是通过不追究责任来建立信任。这个想法不仅适用于你现在的同事，也适用于过去的同事。批评之前的开发人员/工程师与批评现在的同事可能具有相同的效果，只是它给团队对信任的看法增加了一个警示。

“好吧，他们现在并不是想陷害我，但是……”

我还不能说我已经掌握了这项技能。有时，在沮丧的时刻，我会觉得自己完全不行。但我在努力，而这正是这一切的关键所在。每个人都在努力，没有人最终成功，我们越能体会前人所面临的未知限制，我们就会越好。