工作20年的程序员，来自“盘”的五种编程心得本文作者是一名工作20年的程序员。他分享了20年来学到的5条编程经验：重复的知识是最糟糕的，代码被视为一种债务，相信资深开发人员去信任但验证，使用TDD，使用“证据”来证明你的代码是更好的。以下是对这五种经历的具体描述。这一年，我对DEV开发平台越来越熟悉了。在激怒的Reddit评论者和“恰如其分”的鉴赏家的沙漠中，DEV已成为令人耳目一新的正能量绿洲。这个社区有有趣的一面，它似乎非常面向初学者。我经常在这里看到行业新人写的帖子。我所说的菜鸟是指有抱负的程序员在训练营中寻找入门级工作，或者那些在不幸的“初级”程序员职位上工作的人。我觉得有趣的是，这个行业的新人往往有一种具有感染力的热情。他们的热情也让我认识到了自己在这个行业老手（老头）中的地位。在过去的四十、五十年里，行业对程序员的需求急剧增长，以至于程序员的数量总是每五年翻一番。因此，5年以上经验的程序员占据了行业一半以上的岗位。我在这个行业已经将近20年了。其中10年，我的主要职责是编写代码。又做了10年经理，指导新人，就如何管理和实施代码库评估实践向组织提供咨询，目前从事内容营销。所以，我问自己，“如果我能简洁地总结我的经历（假设有人真正关心），我会给新手什么建议？”于是，这篇文章诞生了。以下是我认为从我20年的编程生涯中得到的最重要的教训和收获。1.重复知识是最糟糕的“避免复制粘贴编程！”当你在你的应用程序中复制、粘贴代码，然后调整它（“复制、粘贴、调整”反模式）时，如果没有人打你的手，那么考虑现在举起“尺子”。因为这是一种不好的做法，而且非常随意。比方说，您有一个运行良好的CalculateBill()方法，但是一位产品经理走上前来说，“我们在墨西哥接待新客户，计费方式与您的略有不同。“因此，您复制当前方法，也粘贴它，将其重命名为CalculateBillMexico()，并根据需要调整它。因此，通过这种方式，您会遇到这些问题：如果未来的更改需要对核心逻辑进行调整，并且现在必须对这两个方法进行额外的修改。进行这样的更改时，可能会引入两个错误。您现在已经建立了一个“设计模式”，并且随着您继续在全球范围内扩展，您的代码更新需要一个新的冗余方法另一个。你的工作量会急剧增加。你忘记更改需要更改的内容，从而引入错误只是时间问题。最终，所有这些方法将存在足够多的差异，以至于你无法合理地组合它们来修复一团糟，但不足以阻止有人更新计费规则并更改它20次。这是一团糟。然而，复制粘贴只是表面问题。复制粘贴只是开始。真正的问题是知识重复系统。在你的系统，知识重复可以以多种方式发生，蹩脚的复制粘贴是最明显和笨拙的。查看其他知识重复示例：一个for循环，上面有代码注释，解释了开始、结束和递增。将内联值分配给全局变量，然后（可能）从配置文件中重新分配一个值就是这样。包含“PretaxTotal”、“Tax”和“Total”列的数据库表范围广泛的ERP系统，将客户存储在CRM模块中，然后存储在计费模块中。综上所述，最好的情况是有一个流程和系统来尝试跟踪副本并确保它是最新的。如果缺少代码注释，也许团队的首席唠叨官在更新代码时会一直在你耳边低语：检查注释，检查注释·······或者，如果是ERP系统，这可能是一个严格的部门备忘录告诉销售和会计他们都需要发送正式电子邮件以确保客户信息保持同步。请记住，以上已经是最佳情况。当您开始构建复杂的逻辑以确保同步时，情况会更糟。也许您可以实现一个数据库触发器，以确保当“总计”列发生变化时PretaxTotal+Tax仍然等于总计。或者，您可以编写一些笨拙的状态检查逻辑，当默认全局变量值与配置文件中的值不匹配时记录警告。最坏的情况是数据不同步。好吧，作为一名程序员，您可能不必担心，因为您获得这份薪水的工作不包括弄清楚为什么你们从来不给客户开具发票，或者为什么您向客户多收了钱多年。但是，根除并积极抵制潜伏在整个系统中的问题可以帮助您避免所有这些问题。2.代码是一种债作为开发者，我们要学会热爱代码。编写代码感觉很好，创造一些东西令人兴奋。此外，我们还在寻找新的语言、范例、框架、堆栈、工具、API和库来学习。我们沉浸在自己的世界里，因为在这种状态下，我们可以愉快地产出代码。一些极端的开发人员甚至将每小时生成的代码行数作为生产力的衡量标准。即使没有达到这一点，也很容易认为代码越多越好。代码是杀手级应用和企业的DNA，公司认为它是宝贵的知识产权。然而，代码是关于债务的。少即是多你知道什么比“用10行代码写出别人用100行代码才能完成的事情”更好吗？那是0行代码。写下这行代码：printf("HelloWorld!");你认为有多少事情会出错？此代码是否会在允许控制台打印的环境中运行？那个神奇的字符串以后不会成为问题吗？你不应该登录吗？这是最佳做法。你有没有想过这对安全的影响？保守地说，这行代码中有10处可能出错。现在，我们添加第二行。那么，您认为这会导致总共20件事情可能出错吗？我想应该有将近100件。你可以称我为悲观主义者，但我认为潜在问题与代码行之间的关系更接近组合关系，而不是线性关系。事实上，我做了几年的管理顾问，我看过、分析过、收集过大量代码库的统计数据，我收集过1000多个代码库的详细统计数据，如果算上那些在客户现场自动分析。然后，我对这些数据进行了回归分析，以找出相关性。那么，您知道什么与糟糕的代码库更相关吗？那就是代码库的大小。几乎所有关于代码库的坏事都与其大小有很大关系（以逻辑代码行衡量）。我喜欢代码，我喜欢写它、研究它、分析它，并用它来构建东西。但毫无疑问，代码是一笔巨大的债务，我们应该力争用尽可能少的代码来做每一件事。3.高级开发人员：信任但要验证当我23岁开始第一份软件工程工作时，我对高级开发人员怀有崇敬之情，并从他们身上学到了很多东西。如果您是这个行业的新手，您可能会像我一样认为团队中高级开发人员的每一句话都是骗人的智慧。而且，如果你幸运的话，他们中的很多人都是，尤其是在开始的时候。然而，并不是所有的高级开发人员都是这样的。回想起来，有些人不是技术专家，而是坐在那里半天什么都不做，设法不被解雇，混资晋升为“高级”或“高级”之类的头衔。这种现象非常普遍，以至于我在多年前编了一个词来描述它，现在它每个月都会有数百次谷歌搜索。当我创造“专家初学者”这个词时，它引起了人们的强烈共鸣。所以，当你是新人时，要相信前辈所说的话，尊重他们，但不要理所当然地认为他们说的是对的。你要自己验证，当然最好不要在他们面前验证。4.TDD确实有效，它改变了游戏规则当谈到任何编程时，即使是与技术相关的，我们也倾向于做出有偏见的主观选择。IDEvs轻量级编辑器讨论？苹果、Windows还是Linux？您对PHP感觉如何？Tab（制表符）还是空格（space）？拿出其中任何一个，你就会看到那些观点清晰的人的争论。因此，考虑到所有这些，我意识到我正陷入类似“做TDD还是不做”的境地。我的目的不是说教，而是分享我自己的经历。大约10年前，我是TDD怀疑论者。我不是单元测试怀疑论者，事实上我从一开始就把它当作一种有用的实践来接受，但对TDD不太确定。甚至，在那个时候，我决定写一篇博客来解释为什么TDD不是那么好。但我不想就此事写一篇蹩脚、蹩脚的评论。所以我决定严格按照TDD（固定价格，顺便说一句）做一个小客户项目，这样我就可以写一篇文章，但文章的前提是“我实际上要花几周时间做纯TDD，并发现它不好的事实”。事实上，整个过程可能需要几天时间。每件事都花了我很长时间，而且一切都很繁琐和不自然。我将它们一一记录下来，以证明为什么TDD是一种糟糕的做事方式。但是，我对这种范例非常着迷，以至于我有一天花了4-5个小时编写代码，但没有实际运行应用程序来检查更改是否有效。（通常，我每10分钟左右运行一次该应用程序，以检查所做的更改是否真正起作用。）意识到我已经工作了几个小时，我启动了该应用程序，并感到有必要再调试几个小时。毕竟以前至少要调试30次以上。然而，一切正常，第一次没有任何异常。我花了几个小时编码，但没有查看我的GUI或在运行时验证任何东西，但一切都运行良好。于是，我学习了这项技术，掌握了它，教授了相关的课程，进行了相关的咨询。除此之外，我调查了单元测试对代码库的影响，发现效果无疑是好的。5.证据为王到目前为止，在这篇文章中，我已经提到了我自己的代码库评估实践并讨论了经验数据。那么，让我们开始做正事，从我目前的职业生涯中学到最后一课：证据就是一切！代码审查可以是一种教育和授权活动，也可以执行你的灵魂。然而，代码审查可能会在启发性体验和无意义的争吵之间来回摇摆。您会听到诸如“这不是一个好的设计”或“效率不高”之类的话，您可能也会说这些话。而且，您很可能在没有任何证据的情况下听到或说过这些话。那么，如何解决这个问题呢？证据的重要性如果有人在代码审查期间或在团队或组织中协作时指责您，那么证据就是最好的陈述。如果试图向管理层或领导解释任何事情，证据也是最好的解释。我的意思是，在代码库中找到有和没有全局声明的模块，并使用JIRA问题单事件率或其他数据作为参考。您团队中是否有人要求您使用与您选择的不同的库或API，因为它们“无缘无故”地具有良好的性能？那么，你接受他的说法吗？如果你不接受，那就去证明他说的是错的。例如，进行实时测试。让自己习惯于做实验，而不是大声表达和重复想法。用证据检验想法具有直接价值。面对质疑，有时你会发现自己是对的，有时你会发现自己错了。即使被证明是错误的，它仍然有价值。除此之外，你会开始以一种其他人无法匹敌的方式争论，从而开始给自己打上勤奋和正确的烙印。这可以帮助您克服看似无法逾越的障碍，例如“我只是初学者，他是专家”。事实上，他只是一个专家级的初学者。如果你把眼光放得更长远，这样的操作会让你在事业上有更好的发展。能够编写代码可确保您拥有一份有价值的职业，能够编写代码并使用证据为一系列行动提供技术和业务用例将确保您的职业蒸蒸日上。以健康的方式使用（或不使用）这些，我在写这篇文章时感到很有哲理。事实上，我认为如果你足够努力，你可以反驳这些观点。我不认为这些是一成不变的编程法则或某种职业行为准则，我只是将它们作为我职业生涯中的经验教训提供，它们只是我个人的看法，请谨慎选择。希望这些观点能帮助您根据自己的需要以健康的方式采纳或不采纳它们。作者介绍了DaedTechLLC的创始人、程序员、架构师、IT管理顾问、作家和技术专家ErikDietrich。
