Erik Dietrich：二十年的编程，教会我的五件事！

CSDN翻译

读完需要

11

分钟

速读仅需 4 分钟

无论你是刚入编程的小白，还是已经浸润编程数年的资深人员。相信这篇文章都会给你带来不一样的启发，前人的经验永远是我们最容易看到的捷径。

我想起了 Bob Martin 曾在播客或演讲中说过的一段话。在过去的 4-5 年中，程序员的需求急剧增长，以至于程序员的数量每隔 5 年就会翻一番。结果是，拥有 5 年经验的程序员在这个行业的任职时间甚至超过了该行业的一半。

1

行业的前辈

如今，我已在这个行业中度过了 20 个春秋。其中的 10 年时间里，我的主要工作都是编写代码。而另外 10 年都在管理程序员、指导他们，就如何管理程序员向组织提供咨询，运行代码库评估实践，而如今的我在从事内容营销。但是，无论身处以上哪个职位，我都在或多或少地编写代码。根据上述有关程序员增长速度的估算，我比这个行业中 94%的人都年长。所以，总结起来说，我是一个与编程新手厮混在一起的编程爱好者。于是，我不禁在想：“如果我可以将这段经历总结成一些简短的建议，再假设有人感兴趣，那么我会对他们说什么呢

想象一下，你有一个完美的 CalculateBill()方法，但是产品经理犹豫着说：“我们有一部分客户来自墨西哥，那边的账单计算方式不一样。”于是，你复制了这个方法，重新命名为 CalculateBillMexico()，并根据需要做出调整。这种方法的问题在于：

• 如果将来核心的逻辑需要调整，那么你就必须付出额外的劳动，因为你需要修改两个方法。

• 一旦发生变更，你的代码出 bug 的机会也会加倍。

• 如今你已经建立了一个“设计模式”，随着全球扩张的继续，你的代码还会因为第三个国家而衍生出第三个冗余的方法。

• 随着工作的进展，你的工作量将急剧增加。

• 在修改代码时，你迟早会因为忘记修改所有的方法而产出新 bug。

• 最终，所有这些方法之间都会产生很大的差异，以至于你无法合理地将这些方法合并回去，并从根本上解决问题；即便没有如此大的差异，每当更新账单的计算方式时，你就需要进行 20 次的更改。是不是一塌糊涂这只是“复制-粘贴”的表面问题。

3

复制粘贴只是一个开端

真正的问题在于系统中的知识重复。系统中的知识重复可以以多种方式发生，而无脑地复制粘贴只是最明显和最愚蠢的方式。知识重复的其他形式还包括：for 循环上方的代码注释解释循环的开始、结束和增量。全局变量在程序里赋了一个值，然后从配置文件中重新赋了另一个值。数据库表中同时包含“税前总额”、“税款”以及“总金额”三列。范围很广的 ERP 系统，CRM 模块中存储了客户信息，然后在账单模块中又存储了一次。对于以上所有这些情况来说，最好的打算也不过是通过恰当的流程和系统来认真地跟踪重复并确保同步更新。至于一无是处的代码注释，团队的领导会警告你每次更新代码时，都别忘了检查注释。还有上述的 ERP 系统，销售和会计两个部门都需要严格地制定备忘录，并通过发送正式电子邮件确保客户信息保持同步。

5

少即是多

你知道有人可以用 10 行代码实现别人要 100 行代码才能实现的功能吗么你知道比 10 行代码更好的是什么吗就是 0 行代码。

比如，我们写了一行代码：

• 你知道这中间可能会出多少错吗/p>

• 这行代码是否只能在允许控制台输出的环境中运行/p>

• 这个神奇的字符串将来不会成问题吗/p>

• 你不应该记录日志吗竟日志才是最佳实践。

• 你考虑过这行代码中的安全隐患吗守地说，这行代码可能会出 10 个错误。

• 那么现在，让我们增加到 2 行代码。你是否觉得 2 行代码可能会出 20 个错误认为 2 行出的错误可能会超过 100 个。

• 你可能觉得我过于悲观，但是我认为潜在的问题与代码行数之间的关系更接近排列组合的个数，而非线性关系。

几乎所有与代码库有关的问题都与代码库的大小（以逻辑代码行来衡量）有着显著的关系。我喜欢代码。我喜欢编写代码、研究代码、分析代码，并通过代码来构建事物。但是请不要误解，代码是一个巨大的负债。我们始终应该努力用尽可能少的代码来完成所有工作。

6

高级开发人员：信任，但要自行验证

23 岁时，我开始了第一份软件工程师的工作，我非常敬佩公司里的高级开发人员。Paul、Raymond、Chris、Ken，他们都有 20 年的经验，我至今仍然记得每一个人，而他们熟练使用多种编程语言的能力也让我看傻了眼。我从他们那里学到了很多东西。

我说这些是为了警告你，有很多高级开发只是表面上装出来的，实际上并不称职。因此，在你是新手时，没有确凿的证据就不应该质疑他们，但不要轻易假设他们告诉你的是对还是错。你需要自行验证（最好不要当着他们的面）。

7

TDD（测试驱动开发）不仅有效，而且还可以积极地改变编程的方式

苹果、Windows 还是 Linux/p>

你如何看待 PHP/p>

制表符还是空格/p>

只要提到以上任何一个建议，就会看到持有强烈见解的人们吵得沸反盈天。因此，考虑到所有这些因素，我意识到我自己也陷入了类似的境界：“顺 TDD 者是生存还是毁灭”。我的目的不是给你洗脑，而是分享我的经验。

第一次运行，一切都很完美，竟然没有出现一个异常，也没有发生任何意料之外的事情。我花了几个小时编写代码，中途并没有检查 GUI，也没有在运行时验证，但一切都能正常工作。最终，我写了一篇与预想截然相反的关于 TDD 的文章。从此我就踏上了这条不归之路。我学习了这项技术，掌握了这项技术，教授了有关该技术的课程，并对开发人员进行了指导。但此外之外，我还检查了单元测试对代码库的影响，发现这些影响无疑都是正面的。所以，你也可以尝试学习 TDD，你绝不会后悔。

9

证据才是王道

到目前为止，在这篇文章中，我提到了有关代码库的评估实践，还讨论了经验数据。最后让我再介绍一下职业生涯的最后一课。证据就是一切。代码审查可以作为一种有教育意义的授权活动。同时，代码审查也可以抹杀一个人的灵魂。不过，通常代码审查都在启发性体验和毫无意义的争吵之间来回摇摆。你可能会听到“设计不佳”或“效率不高”之类的反馈。你也可能会说这些话。而且，你极有可能会在没有任何证据的情况下听到或说出这样的话。你需要改正这一点。

10

证据的重要性

如果有人在代码审查或其他形式的团队或组织协作中，以恶劣的态度对待你，那么你就应该拿起证据的武器。如果你想就某件事情向管理层或领导层提出任何想法，那么也应该拿出证据。证据可以帮你赢得辩论、组织、领导角色和职业发展。你不同意团队广泛使用全局变量的做法要做无谓之争，你需要证明。我所说的“证据”并不是指寻找类似于“全局变量的弊端”等文章，或拿权威人士吓唬人。我的意思是查找代码库中没有全局状态的模块，并对照这些模块与 JIRA 问题票的发生率。

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览91970 人正在系统学习中