代码简洁性

友善与代码

软件开发很容易被认为是一项纯粹的技术活动，人类并不重要，一切都是关于计算机。然而，事实恰恰相反。软件工程从根本上说是一门人类学科。

多年来，在试图修复软件开发过程中犯下的许多错误，都是因为只关注系统的技术方面，而没有考虑到编写代码的是人类这一事实。当你看到有人更关心优化而不是代码的可读性，当你看到有人不愿写注释却整天调整他们的shell脚本以减少行数，当你遇到无法沟通却崇拜小二进制文件的人时，你看到的是这个问题的各种症状。

实际上，软件系统是由人编写的。它们被人阅读，被人修改，被人理解或不理解。它们代表了编写它们的开发者的思想。它们是地球上最接近原始思维表达的东西。它们本身并不具有人性、生命、智能、情感、邪恶或善良。是人具有这些品质。软件完全且仅用于服务人类。它们是人的产物，通常是一群必须合作、沟通、相互理解和有效协作的人的产品。因此，关于与一群软件工程师合作有一个重要的观点：在开发社区中对他人残忍毫无价值。

对与你一起工作的人粗鲁无益。愤怒地告诉他们错了，不应该做他们正在做的事情也无济于事。确保应用软件设计法则，让人们遵循一条良好的路径，制作易于阅读、理解和维护的系统，这才有帮助。但这并不需要你残忍。有时你确实必须告诉人们他们没有做对事情。但你可以实事求是地说明——你不必当面指责或人身攻击。

例如，假设有人写了一段糟糕的代码。你有两种方式可以评论这一点：

“我不敢相信你认为这是个好主意。你读过软件设计的书吗？显然你不该这样做。”

这是粗鲁的方式——这是对个人的攻击。另一种告诉他们问题所在的方式是：

“这行代码难以理解，这看起来像代码重复。你能重构一下让它更清晰吗？”

在某种程度上，这里的关键点是你评论的是代码，而不是开发者。但同样，关键点是你不做个混蛋。我的意思是，得了吧。第一种回应显然是粗鲁的。这会让那个人想和你一起工作，想贡献更多代码，或者想变得更好吗？不。另一方面，第二种回应让那个人知道他们走错了路，而你不会让那段糟糕的代码进入代码库。

你阻止那个程序员提交糟糕代码的全部原因首先与人有关。要么是关于你的用户，要么是关于其他必须阅读系统的开发者。通常，两者兼而有之，因为制作一个更可维护的系统完全是为了你能持续有效地帮助用户。但无论如何，你作为软件工程师的工作与人有关。

是的，很多人会阅读代码和使用程序，而你审查代码的那个人只是一个人。所以可能会认为，为了让这个系统对每个人都好，你可以牺牲一些善意。也许你是对的。但为什么在不必粗鲁或残忍的时候要这样做呢？为什么要在你的团队中创造那种让人们害怕做错事的环境，而不是让他们为做对事而感到高兴呢？

这也不仅仅限于代码审查。其他软件工程师有话说。你应该倾听他们，无论你是否同意。礼貌地承认他们的陈述。以建设性的方式向他们传达你的想法。

看，有时人们会生气。要理解。有时你也会生气，当你生气时，你可能希望你的队友能理解。

这一切可能听起来有些虚无缥缈，像某种不重要的心理废话。但看，我并不是说，“每个人总是对的！你应该一直同意每个人！永远不要告诉任何人他们错了！没有人做过任何坏事！”不，人们经常犯错，世界上和软件工程中有许多坏事你必须拒绝。世界并不总是一个好地方。它充满了愚蠢的人。其中一些愚蠢的人是你的同事。但即便如此，对那些愚蠢的人粗鲁也不会让你做出任何有效的事情。他们不需要你的仇恨——他们需要你的同情和帮助。而你的大多数同事可能不是愚蠢的人。他们可能是聪明、善意的个体，有时会犯错，就像你一样。给他们怀疑的好处。与他们合作，保持友善，从而制作更好的软件。

-Max

评论

Nemo 说:
2017年8月12日下午1:27
你的推理有一个明显的缺陷。你在电梯里遇到某人，你礼貌友善。这个人踩了你的脚一次，你礼貌友善。当这个人第三次踩你的脚时会发生什么？第五次呢？情况a. 你是个圣人，死时礼貌友善，情况b. 你只是凡人，在某个时刻你不再礼貌友善。因为你知道，有人一直踩你的脚没有太多理由，实际上只有两个，那家伙要么愚蠢要么坏，两种情况下他都是危险的。是的，你的脚也可能异常长，那家伙不动就会踩到一只。我想在这种情况下你不能和任何人一起在电梯里，所以这个推理再次不适用。

回复

Max Kanat-Alexander 说:
2017年8月12日下午2:50
不。这里的评论似乎没有抓住重点。
首先，你的 fellow developers 没有踩你的脚。他们没有造成你身体上的痛苦甚至攻击你。你没有理由对糟糕的代码或困难的技术讨论做出像对实际身体攻击你的人那样的反应。
其次，再读最后几段，意识到我说过你应该阻止人们做坏事。我不知道你在这里提议做什么能真正解决问题，除了比如，在某个时候报警抓那家伙？我看不出这些如何证明对同事粗鲁是合理的。
-Max

Nemo 说:
2017年8月13日凌晨1:04
我和许多踩过我脚的“ fellow ”开发者一起工作过。根据我的经验，这是因为除了人们常见的所有问题之外，开发者平均而言在与他人相处方面有严重困难，且性格扭曲。
例子数不胜数。相对有趣的，比如你向客户演示新产品，你激活某个功能，却得到了经典的“演示灾难性错误”，但你在屏幕上看到的不是“lorem ipsum”文本，而是一连串的脏话。真正糟糕的，比如客户打电话因为服务器宕机或软件崩溃，而你不在座位上，你的“ fellow ”开发者在那里玩纸牌或看色情内容，不接电话。或者你必须协调在同一软件的不同部分工作，而你的“ fellow ”开发者故意拒绝同意如何做事，反而努力让你的部分尽可能困难，导致整个项目失败，仅仅为了乐趣。更不用说你的“ fellow ”开发者从雇佣你们俩的公司偷东西，一直说谎，伪造分析，试图窃取你的工作或试图为你的成就邀功等等。
此外，这不仅仅是关于工作，当你看看整个“开源”生态系统，Linux 之类的东西，你可以很容易看到人们一直互相踩脚，没有其他原因，只是因为许多人要么愚蠢要么坏（你可以两者兼是，仍然能够编码）。
老兄，你生活在幻想之地。

回复

Max Kanat-Alexander 说:
2017年8月13日凌晨4:17
我明白你说的所有内容，Nemo。
听起来你只是在说人们经常很坏。也许这是真的。但这并不需要粗鲁来修复。当你解雇某人或向人力资源和管理层写关于他们行为的报告时，你甚至不必粗鲁。
注意，听起来你一直处在一个人们持续使坏的环境中，所以也许你迄今为止对此所做的实际上并不奏效。你考虑过这种可能性吗？
-Max

Joe G 说:
2019年9月30日下午3:33
Max – 你的想法与我共鸣，并且一直是我在软件开发中的座右铭。然而，阅读评论后，很明显并非所有人都同意。我的观点已经转向“开明的自我利益”观点，即善待他人而非故意伤害他们符合你自己的最佳利益。我们无意中造成伤害的方式有很多，比如犯简单的错误，别人不得不花数小时修复。对我们行为的正念，对我们编码宇宙中他人的同理心，以及仅仅关心我们所做的事情——很重要——并且会以同样的方式回报给我们。

回复

Max Kanat-Alexander 说:
2019年9月30日下午4:16
太棒了，Joe。我觉得说得真的很好。

Darren S 说:
2017年8月28日下午3:15
我认为作者想表达的观点是，你对坏/负面事件的反应应该引导互动/环境向积极方向发展。如果有人踩了你的脚，积极的反应会是：“打扰一下，你踩到我的脚很痛，我不确定这有什么目的，你能解释一下吗？”。
我也和难相处的开发者一起工作过，我曾经有这种“我不是消极，我是诚实”的态度。但那仍然是消极的，我最终学到，如果我曾经希望其他人改变他们的态度，我能做的就是成为一个积极的影响者，仅此而已。
相信我，我有过初级开发者犯了一些严重的错误，让公司损失了金钱。这非常令人沮丧，尤其是在你事先解释了如何避免这些错误之后。但指责人总会引发负面反应，即使他们不会立即表现出来。
你似乎专注于事情的消极面，没有提供任何解决方案。这正是我提到的那个初级开发者作为高级开发者难以合作的确切原因。一旦我以开放的对话回应，而不是指责，我开始看到他的反应发生了变化，我们开始了讨论而不是争论。
我认为作者这里的观点是，有毒环境中的积极改变必须从积极（或至少是建设性）的对话开始。指出失败而不提供解决方案毫无成效。如果有任何影响，那就是消极影响，使最初的问题更糟。

Mike W. 说:
2017年10月30日下午3:47
为了保持在你的例子/类比中，你不需要粗鲁地对待他来防止他踩你的脚。句号。
事实上，粗鲁地对待他不会阻止或劝阻他踩你的脚。这是“惩罚驱动心理学家”所犯的错误：如果你非常非常用力地踩他的脚，会“教”他当他踩你的脚时会发生坏事，然后他就不会再做了。或者如果你对他尖叫说他是混蛋因为他踩了你的脚，那么他会通过惩罚“学习”并且再也不会踩你的脚。这个理论行不通。（如果你不相信我，下次有人推挤你或踩你的脚时可以试试。对他们尖叫足够多，你可能会挨一拳。）
相反，正如这篇文章最后一段所述，你可能会（冷静地）大声说：“嘿，老兄，你能更仔细看看你走在哪里吗？你刚才踩到我的脚了。”这比粗鲁更可能有效。
你设定了一个完全错误的二分法，声称那个人要么愚蠢要么坏。你有没有想过，当你以这种信念对待他人时，他们自然会对你反应恶劣？而他们对你恼怒或怨恨的行为可以被你解释为他们愚蠢或坏的证据：一个自我证实的假设。试着以你希望他们对待你的方式对待他人，你可能会发现他们对你的行为也有所改善。

Nadav Naor 说:
2017年9月12日上午7:43
我相信文章最后的陈述“与他们合作，保持友善，从而制作更好的软件。”是这里最重要的陈述之一。归根结底，你希望你的团队成功，你希望你的产品/服务成功，你希望花时间做有影响力的事情，而不是仅仅因为现在添加更多功能太复杂而重构/重新设计旧代码。如果你在代码审查中看到你的一个同伴需要纠正，无论是设计方面、可读性还是其他任何方面，你反应得越理智和逻辑（而不是情绪化），你的同伴接受你的审查的机会就越大。此外，有时对方比你更有背景。所以即使有些事情可能看起来不对劲，但实际上这样做是正确的。通过粗鲁，你以后可能会出丑。试着理解是否有好的理由让对方以那种方式编写代码。总之，感谢好文章。

Aleksandra Reszotnik 说:
2017年9月14日凌晨1:55
感谢这篇文章，我非常感激！老实说，我希望生活在一个关于遵守某些文化标准的文章不会因为相当明显而获得任何流行的世界。不幸的是，我们不是；我想不出任何对他人 simply rude 的解释。无论如何，这种趋势正在改变，也因为有像你这样的声音——我很高兴能见证这一点。

Nexle 说:
2017年10月3日晚上8:10
我同意作者的观点。看看软件是如何工作的，而不是批评它的代码。

Saim Aksr 说:
2017年10月19日下午5:30
我也同意，团队成员应该始终互相帮助和友善，帮助其他开发者，让其他人帮助你。这让成功更容易实现。

Roland Askew 说:
2017年10月29日凌晨1:21
完全同意。
重要的是要外交、支持和开放。软件工程可能是一个要求很高的职业，支持的同事有助于韧性。这是一条双向街道。
我认为很多都归结为每个参与者的态度和情感/自我支持技能。不是一个简单的个性衡量标准——随着时间的推移，我遇到了几个刻板印象的内向、逻辑学家、系统思考者类型，他们像所有人一样，有各种风格。
我注意到的导致“残忍”情况的趋势可能包括过度膨胀的虚假自信（参见邓宁-克鲁格效应），对障碍或错误的糟糕反应，对错误的高度自我谴责，强烈的自我防卫（保全面子是一个例子），“被动优势”效应，即其他开发者习惯于更高绩效者承担更高工作量，并抵制受影响的同事寻求的改变（一种边界跨越），糟糕的人际成熟度和技能，包括跨越边界，将不专业的习惯带入工作场所，以及更多。
人们选择职业可能是因为他们避免什么，以及他们提供什么。在后台只与机器相处的刻板印象在某种程度上仍然存在，不幸的是，在可预见的未来，这个职业仍然会吸引并允许那些只想这样做而避免人际关系的人，甚至是那些技术精湛但没有任何人际软技能衡量标准的人。
我想补充一点，人们有极限，有时储备会被职业的压力或需求耗尽。礼貌仍然很重要，尤其是对客户，但对压力过大的团队成员，一点理解和宽容会有很大帮助。为此，公司通过良好的员工提升、支持和保留计划会做得更好。显然，一些现有公司仍然认为这不是他们的责任。

Mike W. 说:
2017年10月30日下午3:35
坦率地说，如果你的评论不是以“完全同意”开头，我会不知道你对此文章主题的立场，尽管我已经读了你的评论四遍。似乎心理学术语的散布并没有帮助有效地向你的听众传递理解或信息。
就个人而言，我更喜欢清晰的工程风格陈述，具有精确和特定的含义，即使讨论与我们职业的人类方面而非技术方面相关的主题。例如，作者的陈述：“在开发社区中对他人残忍毫无价值。”这是一个具有确切含义的陈述，只需要理解所用英语词语的普通意义。（请注意，我并不同意所有陈述必须可简化为数学中的数值意义才具有逻辑有效性的观点。符号逻辑是表达精确思想而不失去细微差别的远弱于书写良好的英语的工具。）他的陈述也是我相信字面上真实且非常有意义的陈述。
再读三遍你的评论后，似乎如果将其重构为简单陈述“友善是在自己身上保持的最重要品质之一，尽管在尝试这样做时可能遇到许多困难和挫折”，其意图将被保留、增强和澄清（就像应用代码简洁性原则时的程序代码一样）。
这也避免了未定义的“心理废话”的混乱，这常常阻碍关于我们职业人类方面的有效沟通——并且 actively 排斥那些更喜欢数据以更有序格式呈现的技术人员。

Eshwar Yaddanapudi 说:
2017年11月11日上午10:06
我几乎在几个月前在我的博客上写了同样的主题，网址是 http://www.yesprasad.com/2016/10/passion-and-compassion-your-companions.html 它谈论了每个人在办公桌上都需要激情和同情心。