完全正常的人会写出多么可怕的代码
完全正常的人会写出多么可怕的代码
原文：https://medium.com/hackernoon/how-terrible-code-gets-written-by-perfectly-sane-people-33451736d300
当我发现我将把一个旧的 Python 代码库移植到 Node 时，我有点兴奋。这类项目总是比普通的代码维护工作给你更多的创作自由，重写别人的代码的挑战让它变得非常有趣。
当我真正看到我们将要工作的东西时，兴奋感明显消失了。遗留代码可能会令人讨厌，但我已经编程 15 年了，只有几次我见过这样的事情。作者创建了他们自己的框架，这是一场完美的反模式风暴:没有分离关注点，混合空格/制表符缩进，同一个概念有多个名称，变量被来自不同但几乎相同的方法的完全相同的数据覆盖，魔术字符串…这种混乱只能是一屋子胡言乱语的猴子从 Google 随机复制代码的产物。
然而，并不是这些代码糟糕的质量激起了我的兴趣，让我写了这篇文章。在那里工作了几个月之后，我发现作者们实际上是一群经验丰富的高级开发人员，拥有良好的技术技能。什么能带领一个有能力的开发团队生产并实际交付这样的东西？我列出了一份清单。这些是即使有经验的团队也会养成的坏习惯，它们会严重影响你的最终产品，任何静态代码检查器或开发方法都无法挽救。
过分重视估算
这个项目的一个重要组成部分是对截止日期的关注，即使这不利于代码质量。如果你的开发人员不得不专注于交付而不是编写好的代码，他们最终将不得不做出补偿来让你满意。他们可以通过两种方式做到这一点:高估和过度承诺，这两种方式都会带来额外的负担。
通常更难高估，因为其对项目成本的影响是显而易见的，所以您的开发人员可能会选择过度承诺，然后跳过重要的工作，例如考虑架构问题，或者如何自动化任务，以便满足不切实际的最后期限。这些任务通常被视为附加值，所以它们会在没有通知的情况下被削减。随着技术债务的积累，产品质量将会下降，并且你会比你真正想要的更晚发现这一点，因为在项目的后期重新组织代码的成本会成倍增加。
作为一个例子，在这个项目中，我会发现明显在其他地方重复的代码，但是看起来人们是如此匆忙地交付，以至于一些开发人员懒得检查其他人以前是否编写过相同的方法或 SQL 查询。
有时估计甚至会有欺骗性。比如敏捷有一个术语叫“速度”。这个想法是计算你的团队能交付多快，并做出必要的改变以更快。问题是不可能在中短期内得出一个准确的速度。平均法则说，你不能看过去的表现来衡量你现在能走多快，因为过去的表现不是未来结果的良好指标。
平均法则是一个外行人的术语，指的是一个小样本成员之间结果的统计分布必须反映结果在整个人口中的分布。
事实上，一个开发人员可以一天编写大量代码，而她在阅读文档并与队友合作后，可以花三天时间编写五行代码。平均估计在短期或中期内不会给你带来有价值的信息。
不重视项目知识
随着项目的进展，您的团队了解了业务、业务背后的概念以及它们之间的联系。他们还在编写代码时了解实现，因为你永远无法完全想象事情会如何发展，以及你将面临哪些挑战。一些业务领域甚至具有内在的复杂性，需要很长时间才能消化。
因为这是对旧代码的完全重写，所以在这方面特别有趣，因为它显示了你的团队的管理层是否理解项目知识，以及它如何影响开发。如果你在一个大项目中，有些模块你没有专家，没有人可以询问，这是一个大的危险信号。重写代码的价值完全在于利用你第一次学到的东西，所以要珍惜这些知识。
如果你让一个不同的团队来重写，就像我的情况一样，你忽略了你所有的学习并且仅仅依靠你新团队的技能，这可能不会弥补信息的缺乏。一个平庸的开发者在重写他自己写的东西时会做得更好，而且他会做得更快，比你把工作完全交给别人要快。
甚至招聘也会受到项目知识的影响。项目携带的信息越多，让人们跟上进度所需的时间就越长，因此，不仅领域知识更有价值，关注雇佣优秀人才也很重要。如果你没有招聘好员工，你会被一个糟糕的团队束缚住，几个月都不会有任何进展。
关注糟糕的指标，如“已关闭的问题”或“每日提交量”
当一个度量成为目标时，它就不再是一个好的度量。古德哈特定律
当我正在加速这个项目时，有人问我为什么另一个开发人员比我更快地解决问题，好像交付更快是一件好事。你可以想象，我看了一眼他的代码，在一行代码中发现了四个 bug。关注这种不可靠的度量标准会让你的项目彻底脱轨，给人们带来和截止日期一样大的压力。
很少有人关注的一个度量是问题的回归率。有一些 bug，比如空指针异常，可能会在很久以后才出现，如果您没有跟踪回归，那么这些 bug 似乎会突然出现。在这种情况下，你永远找不到问题的根源，因为你找错了地方。
最终，重要的是向客户交付了什么，他们对产品有多满意，以及它如何影响他们的底线，但是关注交付质量并忽略提交率或问题关闭等有趣的指标需要很强的自制力。
了解一个指标是否有用的一个好方法是，试着理解它概括了什么样的个人价值观。专注于宣传对细节的关注、良好的沟通技巧和良好的态度的指标，特别是如果它们需要很大的努力来作弊的话。
假设好的过程可以修复坏的人
良好的流程被描绘成商业中的一种银弹。以我的经验来看，一些公司，尤其是那些招聘方法糟糕的大公司，最终会让他们的流程变得越来越严格，以此来控制有毒人员，进而限制团队成员的创作自由。不仅如此，你还需要人们首先正确地执行你的过程，这样它才能工作。
它永无止境，只要解决招聘问题就可以忽略整个问题。人才可以弥补团队中任何其他的低效。这就是支持聪明工作胜过努力工作的全部要点。
开发人员可能特别难以沟通。在这样一个复杂的代码库中，我不得不不断地向他人寻求帮助，而且也不会经常有人乐意拨出时间来帮助我。这并不能反映良好的态度，在艰难的任务中，如果你不得不寻求帮助，并且只能指望你的几个队友既有知识又有意愿来帮你，事情会变得特别紧张。
你需要能够运用常识和良好品味的人，如果你的过程阻碍了他们，他们会叫你出来。每一个构建工具、每一个静态检查器和每一个通信工具都有好的和坏的用例，你需要人们告诉你，而不是盲目地应用几个月前在不同的上下文中看起来不错的东西。
忽略已被证实的实践，如代码审查和单元测试
跟上现代软件开发过程可能不足以让一个脱轨的项目回到它的轨道上，但是如果你想让你的团队保持竞争力，这肯定是必要的。这就是行之有效的实践介入的地方，这里有一些。测试驱动的开发已经被证明可以减少 40%到 90%的缺陷率，同时增加 15%到 35%的开发时间。代码审查也被证明可以减少缺陷率，在某些情况下，比手工测试减少 80%。
想象一下，当我不得不与一位同事合作这个遗留项目，而他的屏幕上显示着记事本时，我是多么沮丧。使用“搜索”来寻找方法在 90 年代可能很流行，但是现在，避免使用诸如现代 ide、版本控制和代码检查等工具会让你退步很多。现在，它们是任何规模的项目都绝对需要的。
要深入了解软件开发中被证明有效的方法，请查阅《制作软件:真正有效的方法，以及我们为什么相信它》这本书。它有一个很好的列表，列出了经过多年研究证实的有价值的实践。
雇佣没有“人际”技能的开发人员
并不是说开发者不能和其他人交流。我自己也曾是一名害羞的开发人员，最终设法站在观众面前做了一次很好的演讲。
当有人甚至不愿意尝试，或者对改善沟通的要求感到恼火时，问题就来了。如果有一件事情比我提到的任何事情更能加快开发时间，那就是改善沟通。特别是当你缩短了距离，并致力于信息的接近时，你就能在工作场所建立更热情、更清晰的联系。另一个人可能在一万英里之外，这没关系。一个 Skype 电话就能把漫长的编码马拉松变成五分钟的修复。
结论
当您通过使用最好的工具、成熟的技术和良好的沟通来支持和鼓励智能工作时，软件开发肯定会更加自然。你不能假设仅仅因为你注册了敏捷或其他工具，其他的都不重要，事情会自己解决。这里有一种协同效应，如果团队设置正确，可以让团队的工作效率成倍提高，如果不注意细节，就会变得非常缓慢和草率。
注:这篇文章是由 TechBeacon 上的原创的。
黑客中午是黑客如何开始他们的下午。我们是 @AMI 家庭的一员。我们现在接受投稿并乐意讨论广告&赞助机会。
要了解更多信息，请阅读我们的“关于”页面、在脸书上给我们点赞/发消息，或者简单地说， tweet/DM @HackerNoon。