二十年的编程，教会我的五件事

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

作者 | Erik Dietrich

译者 |弯月，责编 | maozz

出品 | CSDN（ID：CSDNnews）

以下为译文：

今年，我对DEV社区平台（https://dev.to/）有了很大的了解。在Reddit众多怒气冲冲的评论家以及急于否定他人的鉴赏家中，这个平台积极的正能量宛如一片绿洲，让人眼前一亮，并为我们带来了更广阔的软件世界。

这个社区非常有趣的一面是，社区中似乎有很多初学者。我经常看到新手撰写的帖子以及面向新手的帖子。所谓“新手”，指的是那些渴望成为程序员的人，他们或者在参加培训班，或者在寻找入门级的工作，或者只是不幸被定义为“初级”的角色。

我觉得这很有趣。相对而言，新手对该行业充满更多热情和兴奋。而这种兴奋是富有感染力。

然而，同时也让我感受到我在这个行业中属于前辈了。

我想起了Bob Martin曾在播客或演讲中说过的一段话。

在过去的4-5年中，程序员的需求急剧增长，以至于程序员的数量每隔5年就会翻一番。结果是，拥有5年经验的程序员在这个行业的任职时间甚至超过了该行业的一半。

行业的前辈

如今，我已在这个行业中度过了20个春秋。其中的10年时间里，我的主要工作都是编写代码。而另外10年都在管理程序员、指导他们，就如何管理程序员向组织提供咨询，运行代码库评估实践，而如今的我在从事内容营销。

但是，无论身处以上哪个职位，我都在或多或少地编写代码。

根据上述有关程序员增长速度的估算，我比这个行业中94%的人都年长。

所以，总结起来说，我是一个与编程新手厮混在一起的编程爱好者。

于是，我不禁在想：“如果我可以将这段经历总结成一些简短的建议，再假设有人感兴趣，那么我会对他们说什么呢？”

以上就是这篇文章的背景。下面让我来谈一谈20年编程生涯为我带来的重大教训和收获。

最糟糕的莫过于知识重复

“避免复制粘贴的编程！”

如果你在编写应用程序时，总是靠复制、粘贴和修改代码，如果还没有人因此而拿戒尺打你的手心，那么现在你自己动手吧。

你应该停止这种做法。立刻，马上！这是一种可怕又偷懒的做法。

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

这种方法的问题在于：

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

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

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

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

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

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

是不是一塌糊涂？而这只是“复制-粘贴”的表面问题。

复制粘贴只是一个开端

真正的问题在于系统中的知识重复。

系统中的知识重复可以以多种方式发生，而无脑地复制粘贴只是最明显和最愚蠢的方式。知识重复的其他形式还包括：

for循环上方的代码注释解释循环的开始、结束和增量。

全局变量在程序里赋了一个值，然后从配置文件中重新赋了另一个值。

数据库表中同时包含“税前总额”、“税款”以及“总金额”三列。

范围很广的ERP系统，CRM模块中存储了客户信息，然后在账单模块中又存储了一次。

对于以上所有这些情况来说，最好的打算也不过是通过恰当的流程和系统来认真地跟踪重复并确保同步更新。

至于一无是处的代码注释，团队的领导会警告你每次更新代码时，都别忘了检查注释。

还有上述的ERP系统，销售和会计两个部门都需要严格地制定备忘录，并通过发送正式电子邮件确保客户信息保持同步。

而且，请记住，这些还只是最好的打算。

当你为了确保同步开始构建复杂的逻辑（那么你就必须进行维护——请参照下一节）时，情况就会每况愈下。

也许你只需要实现一个数据库触发器，就可以在“总金额”列发生变化时确保“税前金额”+“税款”=“总金额”。或者，你也可以编写尴尬的状态检查逻辑，当默认的全局变量值与配置文件分配的值不匹配时，记录警告。

糟糕时候，上述情况会造成数据不同步。然而，作为程序员，你可能不必担心，因为你的工作也包括弄清楚为什么多年来从未给某个客户开过发票或多收了客户很多钱。

然而，根除系统中出现的知识重复问题并积极抵制，就可以避免所有这些情况。

代码是负债

作为开发人员，我们喜欢写代码。写代码的感觉非常好，而且构建软件令人兴奋。

此外，我们还需要学习新的语言、范例、框架、技术栈、工具、API和库。我们沉浸在自己的内心世界，享受快乐地编写代码的状态。

然而，沉浸在代码世界而不自知的不止我们。

被误导的秃头老板甚至用每小时生成的代码行数作为生产力的度量指标。但是即便你没有那么愚蠢，也很容易认为代码自然是越多越好。事实上，代码是应用程序和业务的杀手，而各个公司却把它当成有价值的知识产权。

还是忘记这些无稽之谈吧。

我能理解为什么我们将代码视为资产。但是实际上代码完全是负债。

少即是多

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

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

printf(“Hello World!”);

你知道这中间可能会出多少错吗？

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

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

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

• 你考虑过这行代码中的安全隐患吗？

保守地说，这行代码可能会出10个错误。那么现在，让我们增加到2行代码。

你是否觉得2行代码可能会出20个错误？

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

我有多年专业管理顾问的经验。我做过数据驱动代码库的评估，并帮助IT领导者制定有关代码库的战略决策。

因此，我有机会查看、分析和收集大量代码库的统计信息。

如果算上我利用自动化分析过的客户端代码库之上的代码库的话，那么我总共收集了1000多个代码库的详细统计信息。在获取这些数据后，我进行了回归分析，以寻找相关性。

你知道对代码库造成负面影响最大的因素是什么吗？代码库的大小。

几乎所有与代码库有关的问题都与代码库的大小（以逻辑代码行来衡量）有着显著的关系。

我喜欢代码。

我喜欢编写代码、研究代码、分析代码，并通过代码来构建事物。但是请不要误解，代码是一个巨大的负债。我们始终应该努力用尽可能少的代码来完成所有工作。

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

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

我从他们那里学到了很多东西。

我之所以提到这些，是因为我想过渡到接下来要说的话。

如果你是这个行业的新手，那么可能就会像我一样，认为团队里高级开发人员的每句话都是金玉良言。而且如果你幸运的话，很多高级开发人员确实是不可多得的人才。

然而，并非所有高级开发人员的水平都相同。

回想起来，我上面提到的同事都是优秀的程序员，我从他们那里学到了很多东西。但是，我也明白在我的职业生涯中，最初的经历都很幸运。

很多公司拥有很多出色的高级开发人员，但也有很多公司拥有的高级开发人员较少，或者他们的高级开发人员在技术上并不过关，但是这些高级开发人员仍然任职很久，迟迟没有被解雇，甚至可能得到晋升，顶着“高级”或“首席”的头衔。

这种现象非常普遍，甚至有人称之为“专家级初学者”。

我说这些是为了警告你，有很多高级开发只是表面上装出来的，实际上并不称职。

因此，在你是新手时，没有确凿的证据就不应该质疑他们，但不要轻易假设他们告诉你的是对还是错。你需要自行验证（最好不要当着他们的面）。

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

在涉及任何与编程或技术相关的问题时，身处该行业的我们都会带有偏见。

• IDE与轻量级编辑器之争？

• 苹果、Windows还是Linux？

• 你如何看待PHP？

• 制表符还是空格？

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

我的目的不是给你洗脑，而是分享我的经验。

大约在10年前，我对TDD持怀疑态度。请注意，我不是一个单元测试怀疑论者，刚开始的时候我就同意这是一种很有帮助的做法。

但是对于TDD？我不太确定。

我决定写一篇博客，介绍为什么TDD并不是那么出色。

但是，我不想就此事写一篇文章表达站不住脚的廉价观点。因此，我决定严格按照TDD建立一个小型客户项目，然后我就可以在文章中写：“我花了几周的时间来验证TDD，结果却并不美丽。”

然而，命运总是充满了意外惊喜。

对TDD的幡然醒悟

那天真是尴尬又怪异。确切来说是好几天。

整个过程非常漫长，我所作的一切都非常笨拙且不自然。我记录了一条又一条笔记，作为证明TDD很糟糕的证据。

然而，后来发生了一件有趣的事情。

我对这种笨拙的范例非常着迷，每天我都花4-5个小时编写代码，但中间并没有停下来实际运行应用程序，检查我的更改是否有效。换做往常，每隔10分钟我就会运行一次应用程序，检查程序是否正确，看看我的更改是否确实有效。

在发现自己已经写了几个小时的代码后，我启动了应用程序，叹了口气，以为接下来就是长达几个小时的调试。毕竟，我推迟了将近30个周期。

然而，神奇的事情发生了，一切都能正常工作。

第一次运行，一切都很完美，竟然没有出现一个异常，也没有发生任何意料之外的事情。我花了几个小时编写代码，中途并没有检查GUI，也没有在运行时验证，但一切都能正常工作。

最终，我写了一篇与预想截然相反的关于TDD的文章。从此我就踏上了这条不归之路。

我学习了这项技术，掌握了这项技术，教授了有关该技术的课程，并对开发人员进行了指导。但此外之外，我还检查了单元测试对代码库的影响，发现这些影响无疑都是正面的。

所以，你也可以尝试学习TDD，你绝不会后悔。

证据才是王道

到目前为止，在这篇文章中，我提到了有关代码库的评估实践，还讨论了经验数据。最后让我再介绍一下职业生涯的最后一课。

证据就是一切。

代码审查可以作为一种有教育意义的授权活动。同时，代码审查也可以抹杀一个人的灵魂。

不过，通常代码审查都在启发性体验和毫无意义的争吵之间来回摇摆。

你可能会听到“设计不佳”或“效率不高”之类的反馈。你也可能会说这些话。而且，你极有可能会在没有任何证据的情况下听到或说出这样的话。

你需要改正这一点。

证据的重要性

如果有人在代码审查或其他形式的团队或组织协作中，以恶劣的态度对待你，那么你就应该拿起证据的武器。如果你想就某件事情向管理层或领导层提出任何想法，那么也应该拿出证据。

证据可以帮你赢得辩论、组织、领导角色和职业发展。

你不同意团队广泛使用全局变量的做法？不要做无谓之争，你需要证明。

我所说的“证据”并不是指寻找类似于“全局变量的弊端”等文章，或拿权威人士吓唬人。我的意思是查找代码库中没有全局状态的模块，并对照这些模块与JIRA问题票的发生率。

你们团队中是否有人要求你不要使用你选择的库或API，只是因为某种模棱两可的性能问题？你会服气吗？

那就证明这个人错了。实际动手试试看。

你需要习惯于动手实验，而不是大声表达自己的观点或加倍考虑。这可以直接验证你自己的想法。

有时，你会意识到自己的怀疑是对的。而有时，你会意识到自己错了，这都很有价值。

但更重要的是，你可以提出别人无法反驳的论点，并树立勤奋和正确的好名声。这种做法还可以帮助你克服看似无法克服的困难，例如“我只是个新人，而他是高级工程师（专家级初学者）”。

更进一步，这还可以为你的职业发展奠定基础。

编写代码的能力可以让你收获一份收入丰厚的职业。能够编写代码并通过证据提供技术和业务上的决策可以确保你的职业生涯迅速取得成功。

你是否愿意听取以上意见？

我感觉这篇文章富有哲理。实际上，我是在芝加哥飞往休斯敦的飞机上写下了这篇文章，当时的我端着一杯酒，又无法使用wifi。在百无聊赖中，我只能与空姐交谈，然后就回忆起了我的职业生涯。

我认为如果你足够努力，就可以就这些观点进行辩论。

但是，我不打算将这些作为一成不变的编程法则或某种专业行为的准则。我会把这些我在职业生涯中所学到的教训作为课程，并附上警告事项，因为这些只是我个人的观点。

最后，希望这些意见对你有所帮助。你可以自行决定是否听取这些意见。

原文：https://daedtech.com/5-things-ive-learned-in-20-years-of-programming/

本文为 CSDN 翻译，转载请注明来源出处。