Erik Dietrich：二十年的编程，教会我的五件事！
CSDN翻译
读完需要
11分钟速读仅需 4 分钟
无论你是刚入编程的小白，还是已经浸润编程数年的资深人员。相信这篇文章都会给你带来不一样的启发，前人的经验永远是我们最容易看到的捷径。
作者 | Erik Dietrich
译者 |弯月，责编 | maozz
出品 | CSDN（ID：CSDNnews）
以下为译文：
今年，我对 DEV 社区平台 https://dev.to/有了很大的了解。在 Reddit 众多怒气冲冲的评论家以及急于否定他人的鉴赏家中，这个平台积极的正能量宛如一片绿洲，让人眼前一亮，并为我们带来了更广阔的软件世界。这个社区非常有趣的一面是，社区中似乎有很多初学者。我经常看到新手撰写的帖子以及面向新手的帖子。所谓“新手”，指的是那些渴望成为程序员的人，他们或者在参加培训班，或者在寻找入门级的工作，或者只是不幸被定义为“初级”的角色。我觉得这很有趣。相对而言，新手对该行业充满更多热情和兴奋。而这种兴奋是富有感染力。然而，同时也让我感受到我在这个行业中属于前辈了。
我想起了 Bob Martin 曾在播客或演讲中说过的一段话。在过去的 4-5 年中，程序员的需求急剧增长，以至于程序员的数量每隔 5 年就会翻一番。结果是，拥有 5 年经验的程序员在这个行业的任职时间甚至超过了该行业的一半。
1
行业的前辈
如今，我已在这个行业中度过了 20 个春秋。其中的 10 年时间里，我的主要工作都是编写代码。而另外 10 年都在管理程序员、指导他们，就如何管理程序员向组织提供咨询，运行代码库评估实践，而如今的我在从事内容营销。但是，无论身处以上哪个职位，我都在或多或少地编写代码。根据上述有关程序员增长速度的估算，我比这个行业中 94%的人都年长。所以，总结起来说，我是一个与编程新手厮混在一起的编程爱好者。于是，我不禁在想：“如果我可以将这段经历总结成一些简短的建议，再假设有人感兴趣，那么我会对他们说什么呢？”
2
最糟糕的莫过于知识重复
“避免复制粘贴的编程！”如果你在编写应用程序时，总是靠复制、粘贴和修改代码，如果还没有人因此而拿戒尺打你的手心，那么现在你自己动手吧。你应该停止这种做法。立刻，马上！这是一种可怕又偷懒的做法。
想象一下，你有一个完美的 CalculateBill()方法，但是产品经理犹豫着说：“我们有一部分客户来自墨西哥，那边的账单计算方式不一样。”于是，你复制了这个方法，重新命名为 CalculateBillMexico()，并根据需要做出调整。这种方法的问题在于：
如果将来核心的逻辑需要调整，那么你就必须付出额外的劳动，因为你需要修改两个方法。
一旦发生变更，你的代码出 bug 的机会也会加倍。
如今你已经建立了一个“设计模式”，随着全球扩张的继续，你的代码还会因为第三个国家而衍生出第三个冗余的方法。
随着工作的进展，你的工作量将急剧增加。
在修改代码时，你迟早会因为忘记修改所有的方法而产出新 bug。
最终，所有这些方法之间都会产生很大的差异，以至于你无法合理地将这些方法合并回去，并从根本上解决问题；即便没有如此大的差异，每当更新账单的计算方式时，你就需要进行 20 次的更改。是不是一塌糊涂？而这只是“复制-粘贴”的表面问题。
3
复制粘贴只是一个开端
真正的问题在于系统中的知识重复。系统中的知识重复可以以多种方式发生，而无脑地复制粘贴只是最明显和最愚蠢的方式。知识重复的其他形式还包括：for 循环上方的代码注释解释循环的开始、结束和增量。全局变量在程序里赋了一个值，然后从配置文件中重新赋了另一个值。数据库表中同时包含“税前总额”、“税款”以及“总金额”三列。范围很广的 ERP 系统，CRM 模块中存储了客户信息，然后在账单模块中又存储了一次。对于以上所有这些情况来说，最好的打算也不过是通过恰当的流程和系统来认真地跟踪重复并确保同步更新。至于一无是处的代码注释，团队的领导会警告你每次更新代码时，都别忘了检查注释。还有上述的 ERP 系统，销售和会计两个部门都需要严格地制定备忘录，并通过发送正式电子邮件确保客户信息保持同步。
4
代码是负债
作为开发人员，我们喜欢写代码。写代码的感觉非常好，而且构建软件令人兴奋。此外，我们还需要学习新的语言、范例、框架、技术栈、工具、API 和库。我们沉浸在自己的内心世界，享受快乐地编写代码的状态。
5
少即是多
你知道有人可以用 10 行代码实现别人要 100 行代码才能实现的功能吗？那么你知道比 10 行代码更好的是什么吗？那就是 0 行代码。
比如，我们写了一行代码：
printf(“Hello World!”);
你知道这中间可能会出多少错吗？
这行代码是否只能在允许控制台输出的环境中运行？
这个神奇的字符串将来不会成问题吗？
你不应该记录日志吗？毕竟日志才是最佳实践。
你考虑过这行代码中的安全隐患吗？保守地说，这行代码可能会出 10 个错误。
那么现在，让我们增加到 2 行代码。你是否觉得 2 行代码可能会出 20 个错误？我认为 2 行出的错误可能会超过 100 个。
你可能觉得我过于悲观，但是我认为潜在的问题与代码行数之间的关系更接近排列组合的个数，而非线性关系。
几乎所有与代码库有关的问题都与代码库的大小（以逻辑代码行来衡量）有着显著的关系。我喜欢代码。我喜欢编写代码、研究代码、分析代码，并通过代码来构建事物。但是请不要误解，代码是一个巨大的负债。我们始终应该努力用尽可能少的代码来完成所有工作。
6
高级开发人员：信任，但要自行验证
23 岁时，我开始了第一份软件工程师的工作，我非常敬佩公司里的高级开发人员。Paul、Raymond、Chris、Ken，他们都有 20 年的经验，我至今仍然记得每一个人，而他们熟练使用多种编程语言的能力也让我看傻了眼。我从他们那里学到了很多东西。
我之所以提到这些，是因为我想过渡到接下来要说的话。如果你是这个行业的新手，那么可能就会像我一样，认为团队里高级开发人员的每句话都是金玉良言。而且如果你幸运的话，很多高级开发人员确实是不可多得的人才。然而，并非所有高级开发人员的水平都相同。回想起来，我上面提到的同事都是优秀的程序员，我从他们那里学到了很多东西。但是，我也明白在我的职业生涯中，最初的经历都很幸运。很多公司拥有很多出色的高级开发人员，但也有很多公司拥有的高级开发人员较少，或者他们的高级开发人员在技术上并不过关，但是这些高级开发人员仍然任职很久，迟迟没有被解雇，甚至可能得到晋升，顶着“高级”或“首席”的头衔。这种现象非常普遍，甚至有人称之为“专家级初学者”。
我说这些是为了警告你，有很多高级开发只是表面上装出来的，实际上并不称职。因此，在你是新手时，没有确凿的证据就不应该质疑他们，但不要轻易假设他们告诉你的是对还是错。你需要自行验证（最好不要当着他们的面）。
7
TDD（测试驱动开发）不仅有效，而且还可以积极地改变编程的方式
在涉及任何与编程或技术相关的问题时，身处该行业的我们都会带有偏见。IDE 与轻量级编辑器之争？
苹果、Windows 还是 Linux？
你如何看待 PHP？
制表符还是空格？
只要提到以上任何一个建议，就会看到持有强烈见解的人们吵得沸反盈天。因此，考虑到所有这些因素，我意识到我自己也陷入了类似的境界：“顺 TDD 者是生存还是毁灭”。我的目的不是给你洗脑，而是分享我的经验。
大约在 10 年前，我对 TDD 持怀疑态度。请注意，我不是一个单元测试怀疑论者，刚开始的时候我就同意这是一种很有帮助的做法。但是对于 TDD？我不太确定。我决定写一篇博客，介绍为什么 TDD 并不是那么出色。但是，我不想就此事写一篇文章表达站不住脚的廉价观点。因此，我决定严格按照 TDD 建立一个小型客户项目，然后我就可以在文章中写：“我花了几周的时间来验证 TDD，结果却并不美丽。”然而，命运总是充满了意外惊喜。
8
对 TDD 的幡然醒悟
那天真是尴尬又怪异。确切来说是好几天。整个过程非常漫长，我所做的一切都非常笨拙且不自然。我记录了一条又一条笔记，作为证明 TDD 很糟糕的证据。然而，后来发生了一件有趣的事情。我对这种笨拙的范例非常着迷，每天我都花 4-5 个小时编写代码，但中间并没有停下来实际运行应用程序，检查我的更改是否有效。换做往常，每隔 10 分钟我就会运行一次应用程序，检查程序是否正确，看看我的更改是否确实有效。在发现自己已经写了几个小时的代码后，我启动了应用程序，叹了口气，以为接下来就是长达几个小时的调试。毕竟，我推迟了将近 30 个周期。然而，神奇的事情发生了，一切都能正常工作。
第一次运行，一切都很完美，竟然没有出现一个异常，也没有发生任何意料之外的事情。我花了几个小时编写代码，中途并没有检查 GUI，也没有在运行时验证，但一切都能正常工作。最终，我写了一篇与预想截然相反的关于 TDD 的文章。从此我就踏上了这条不归之路。我学习了这项技术，掌握了这项技术，教授了有关该技术的课程，并对开发人员进行了指导。但此外之外，我还检查了单元测试对代码库的影响，发现这些影响无疑都是正面的。所以，你也可以尝试学习 TDD，你绝不会后悔。
9
证据才是王道
到目前为止，在这篇文章中，我提到了有关代码库的评估实践，还讨论了经验数据。最后让我再介绍一下职业生涯的最后一课。证据就是一切。代码审查可以作为一种有教育意义的授权活动。同时，代码审查也可以抹杀一个人的灵魂。不过，通常代码审查都在启发性体验和毫无意义的争吵之间来回摇摆。你可能会听到“设计不佳”或“效率不高”之类的反馈。你也可能会说这些话。而且，你极有可能会在没有任何证据的情况下听到或说出这样的话。你需要改正这一点。
10
证据的重要性
如果有人在代码审查或其他形式的团队或组织协作中，以恶劣的态度对待你，那么你就应该拿起证据的武器。如果你想就某件事情向管理层或领导层提出任何想法，那么也应该拿出证据。证据可以帮你赢得辩论、组织、领导角色和职业发展。你不同意团队广泛使用全局变量的做法？不要做无谓之争，你需要证明。我所说的“证据”并不是指寻找类似于“全局变量的弊端”等文章，或拿权威人士吓唬人。我的意思是查找代码库中没有全局状态的模块，并对照这些模块与 JIRA 问题票的发生率。
你们团队中是否有人要求你不要使用你选择的库或 API，只是因为某种模棱两可的性能问题？你会服气吗？
那就证明这个人错了。实际动手试试看。你需要习惯于动手实验，而不是大声表达自己的观点或加倍考虑。这可以直接验证你自己的想法。有时，你会意识到自己的怀疑是对的。而有时，你会意识到自己错了，这都很有价值。但更重要的是，你可以提出别人无法反驳的论点，并树立勤奋和正确的好名声。这种做法还可以帮助你克服看似无法克服的困难，例如“我只是个新人，而他是高级工程师（专家级初学者）”。更进一步，这还可以为你的职业发展奠定基础。编写代码的能力可以让你收获一份收入丰厚的职业。能够编写代码并通过证据提供技术和业务上的决策可以确保你的职业生涯迅速取得成功。
11
你是否愿意听取以上意见？
我感觉这篇文章富有哲理。实际上，我是在芝加哥飞往休斯敦的飞机上写下了这篇文章，当时的我端着一杯酒，又无法使用 wifi。在百无聊赖中，我只能与空姐交谈，然后就回忆起了我的职业生涯。我认为如果你足够努力，就可以就这些观点进行辩论。但是，我不打算将这些作为一成不变的编程法则或某种专业行为的准则。我会把这些我在职业生涯中所学到的教训作为课程，并附上警告事项，因为这些只是我个人的观点。最后，希望这些意见对你有所帮助。你可以自行决定是否听取这些意见。
原文：https://daedtech.com/5-things-ive-learned-in-20-years-of-programming/
本文为 CSDN 翻译，转载请注明来源出处。
扩展阅读
架构师成长系列