每年少吸？[关闭]

每年吸吮更少-杰夫·阿特伍德

我看过这篇有见地的文章，直接从帖子中引用

我经常认为，每年吸吮更少是程序员谦虚的进步。您应该对一年前编写的代码不满意。如果不是，则意味着A）一年没有学到任何东西，B）您的代码无法改进，或C）您从不重访旧代码。所有这些对于软件开发人员来说都是垂死的吻。

1. 这种情况多久发生一次或不发生在您身上？
2. 您需要多长时间才能看到编码方面的实际改进？月，年？
3. 您是否曾经浏览过您的旧代码？
4. 您的旧代码多久困扰您一次？或者您必须多久处理一次技术债务。

修复旧的错误和肮脏的代码（这可能是很痛苦的），我们可能会为了快速地按时完成任务而执行这些快速修复，在某些情况下，我们可能不得不重写大多数应用程序/代码。没有争论。

我遇到的一些开发人员争辩说，他们已经处在进化阶段，他们的编码不需要改进或无法得到改进。

• 这会发生吗？
• 如果是这样，那么人们期望这种情况会发生多少年？

有关：

是否曾经回头看过您的某些旧代码和痛苦中的鬼脸？

代码中的 “ 星球大战时刻”：“卢克！我是你的代码！” “不！不可能！不可能！”

  > Sucking Less Every Year ?

没有，但吸吮不同的每年 :-)

多年前我的第一次评论后，我遭受了缺少命名约定的痛苦。

然后，我遭受了我的编码被（不必要地）实现为尽可能通用的痛苦，但这使代码难以理解和维护。

然后，我租用了测试驱动的开发，InversionOfControl，什么是点网泛型以及更多内容。

结论

旧的坏习惯的痛苦减少了，但由于我学到了更多的东西，我被新的痛苦所弥补。

有趣的是，我曾经与之合作的所有“摇滚明星”程序员都非常谦虚，热衷于学习，并愿意承认他们并不了解所有东西。哎呀，至少在轻松的时刻，许多人实际上是自嘲的。

我认为我从未见过一个开发人员认为他们的编码“无法改进”，但是有消息告诉我，这些人离摇滚明星远了-要说得通一点。

以下几点不是建议，而是个人日志：

• 使用更少的全局变量
• 不要对变量或函数名使用缩写
• 编写[一些]测试代码
• 在没有基准测试的情况下，不要将代码判断为慢速（或快速）
• 了解如何对应用进行负载测试
• 如果它还没有破裂，请不要修复
• 使用源代码管理工具（git / hg）
• 重构很酷，不要低估它带来的测试成本
• 安全是很难的，所以要提防这一点
• 修补一些开源项目错误
• 博客新事物
• 可用性可能不是功能要求，但很重要

我一年之内没有学到所有东西，所有事情都需要时间...

通常，人们认为好的代码只是突然发生的，但是对于我们大多数人来说，凡事都是好的代码在我们的代码库中增长。我的意思是，从一开始就很难编写出完美的软件，因为需求在不断变化，而且我们也不是完美的程序员，因此管理者和程序员也经常做出愚蠢的决定。然后，我看到每个需求都改变了一个很好的机会，可以将一些旧代码重构为更好的代码（并为此付费！）并偿还了一些技术债务。正如他们所说：“每次提交代码时，都要使代码存储库更好”。然后，您的系统将演变为更接近理想的系统。

我绝对不知道有哪个程序员为他的软件感到骄傲，但这很好。比意味着程序员已经在过程中学习了。

另外，如果您读过“清洁代码”这本书，那么您将多次增加自己的代码“吸引因子”。：D

实际上，我对此两面都有。

一方面，您查看旧代码，发现其中充满了错误和复杂的处理方式，这些处理方式只是通过利用您当时不了解的技术和语言功能而轻松完成的。

另一方面，您发现了一个特别优雅的问题解决方案，并且不由自主地对自己当时的聪明程度笑了笑。

然后，由于在C语言中使用了GOTO，因此惊恐地向下滚动了几行，做出了鬼脸的准备。

嗯...我的很多旧代码常常令我感到惊喜。

如果我今天要做的话，我经常会写不同的话，但是如果我不得不忍受时间的限制，我不确定会不会。当您可以指望至少具有几GB RAM的典型机器时，与大型硬盘驱动器为100兆字节时相比，您可以（通常应该）编写代码略有不同。

1. 这种情况多久发生一次或不发生在您身上？

2. 您需要多长时间才能看到编码方面的实际改进？月，年？

3. 您是否曾经浏览过您的旧代码？

4. 您的旧代码多久困扰您一次？或者您必须多久处理一次技术债务。

1. 每次我学习新东西时，希望那是每天。

2. 如果我要实现所学知识，则从实现之时起立即执行。

3. 是的，仅适用于（1）新功能，（2）错误修复，（3）怀旧之情，（4）看看我如何解决问题，才有用。

4. 与1.相关，当我学习如何做得更好时，我知道一些“可以”做得更好的旧项目。我离开他们。只要确保下一个项目以更好的方式完成即可。我不担心，除非它是一个实际的错误。

在另一个问题中，主题是关于评估自己代码质量的方法。我的建议之一是在几年内进行复习，那时您的经验比编写代码时要高得多。我对另一个问题的回答的一句话与您的问题直接相关：

“在我的情况下，寿命为一年：这意味着我可以修改六个月前编写的代码，但是如果代码是两年前编写的，则很有可能被抛出，然后被完全重写，因为太烂了。”

因此，是的，实际上，从一年的角度来看，我编写的每段代码都变得难以忍受。我说的不是一次性的代码，而是我在编写代码时就牢记的质量，可维护性和可读性。目前，没有例外。

要回答有关寿命的第二个问题，它有很大的不同。一次性代码的寿命为零秒：编写代码后即会烂掉，但这并不重要。一些代码片段我已经写了可以承受的两年后，但需要一些化妆品的变化：有点重构的，强制执行的规则了StyleCop等。平均而言，我的准确情况下，寿命变化八个月至一年的C＃，PHP则需要两个六个月。

我会重新查看旧代码吗？是的，当然，作为每个开发人员，除非您不关心DRY并一次又一次地重新发明自己的轮子。如果您有在许多项目中使用的通用代码库，也有机会非常频繁地检查和改进代码。另一点是，如果您从事大型项目，有些项目可能会花费您数年时间，因此您将不得不重新查看旧代码。

我遇到的一些开发人员争辩说，他们已经处在进化阶段，他们的编码不需要改进或无法得到改进。

当一个人说她是如此完美，以至于不需要学习任何东西时，这意味着她甚至无法理解自己的愚蠢程度。

即使您在计算机/编程方面拥有二十年的经验，但事情变化太快，因此总会有新的东西需要学习，并且需要新的技术来改进代码。例如，使用.NET Framework 3.0编写的C＃代码很可能可以通过我们今天拥有的新内容（包括Linq，代码合同等）来提高可读性和更好性，即使旧代码也是如此。由最聪明的开发人员编写。

当我查看代码并想知道“编写此代码时我在想什么？”时，它经常发生。

通常总是会有改进，因为有时会出现组织代码，样式化代码或其他内容的新想法，尽管这可能不是一个很大的改进，但每件事都可以有所帮助。

根据工作环境的不同，我可能会在几年前看到代码，因为我继续在同一代码库中工作，并且对其中的内容和要管理的东西非常熟悉。

旧代码几乎总是困扰我，因为通常我是在更改现有系统或更换系统。无论哪种情况，我都必须了解现有系统的怪癖，以确保它们在新的怪癖中存在。

虽然我敢肯定像Jon Skeet这样的人可以思考出完美的代码，但其他大多数人却说他们的代码无法改进，他们说的是，从自我角度来看，这很可能没有吸引力。同时，就每次发现重大改进而言，情况并非总是如此。

1.这种情况多久发生一次？

我多久对旧代码感到不满意？几乎总是。我有令我引以为豪的代码的情况很少见，但是同样，它们很少见。有人告诉我，我几年前编写的代码很好。我畏缩了一下，以为“您这个可怜的穷人，因为看到的情况比我编写的垃圾还糟。”

2.您需要多长时间才能看到编码上的实际改进？月，年？

它通常是分阶段进行的……我真的很喜欢一种样式或方法（例如，流利的界面……因为那是我为之付出巨大努力的最后一种样式），然后花了我一个月或四个月的所有时间。然后它开始看起来更好。

3.您是否曾经浏览过旧代码？

不像我想要的那样频繁。我的大部分旧代码是以前的雇主所有的。个人代码经常被粉刷。

4.您的旧代码多久困扰您一次？或者您必须多久处理一次技术债务。

由于以前的雇主拥有我的大部分旧密码，而我却粉刷了我的大部分个人密码……一点也不经常。