作者 | 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 翻译，转载请注明来源出处。
