停止俯瞰细节

Question

与本网站上的大多数人相比，我无疑是新手。我想从专业人士那里获得一些建议，以避免在代码中出现愚蠢的错误。

当他们第一次开始错过一些导致大问题的细节时，有没有其他人遇到过这个问题？是否有任何习惯或行为可以帮助你解决这个问题。

Answer 1

以下列出了常见的陷阱和/或避免它们的建议：

1. 经验，避免错误的最佳方法就是让他们碰巧遇到你。
2. 查看其他人的代码
3. 让其他人审核您的代码
4. 使用源代码管理，即使您是唯一的开发人员
5. 在提交源代码管理之前查看所有更改
6. 考虑使用更现代的语言，让你更难犯错误
7. 广泛评论您的代码
8. 及早重构您的代码
9. 在添加功能之前修复错误
10. 创建大量的测试用例，因为了解您的错误可以帮助您更快地避免未来的错误。
11. 学习和使用设计模式。
12. 不惜一切代价避免代码重复，尽量不要复制/粘贴代码块
13. 了解您正在使用的编程语言中的特定常见缺陷

Answer 2

我发现在开始编码之前，或者至少在我脑海中编写代码或算法。它会让你的问题更加清晰，你不会只是开始编码，而你可能会犯下愚蠢的错误。

Answer 3

我发现如果我在将所有代码提交到版本控制之前通读差异，我几乎保证找到一些错误。如果我有其他人在检查代码时检查代码，则会产生双重影响（至少）。

Answer 4

同行代码审查和单元测试。只有经验才能帮助你避免犯错误，但这些事情会帮助你了解你早期犯的错误。

Answer 5

就像你将在生活中做的其他事情一样。从在当地一家快餐店的炸锅里烧自己，到在他/她的第三家创业公司担任企业家。

从他们那里

犯错误，学习，更好 自己 - 不要忽略他们

Answer 6

与大多数其他获得的技能一样，练习也很完美。继续训练。

Answer 7

我会再加上“练习完美”的投票，但稍作修改：

完美的练习是完美的 - 一个相关的说法是“练习永久”，换句话说，确保你所练习的是良好的编码习惯，减少错误：

• 单元测试
• 可读代码格式
• 有用的变量名称
• 修订历史的源代码管理

等等。我还高度推荐看看好的开源项目，看看他们如何组织和管理代码。好的例子比从其他人的错误中学习更重要： - ）

Answer 8

我发现，如果我在尝试修复错误或想出问题时遇到任何特殊问题，我将花5分钟休息一下。当我喝点东西或只是放松并回到问题时，我往往更专注，压力更小。

Answer 9

模式 - 在您的工作中开发或借用和使用模式。一些示例模式：变量名称的一致使用，递增计数器的一致位置，错误报告的一致放置等等。

有效使用模式的一个重要方面是它们的视觉外观。一个令我惊讶的常见用法是在一行的末尾而不是在下一行的开头放置开括号。例如，这是一个很好的做法：

void MyMethod(String some_input)
{
   if (some_input == null)
   {
      some_input = "";
   }
}

使用常见但不好的做法编写的相同方法如下所示：

void MyMethod(String some_input) {
  if (some_input == null) {
    some_input = "";
  }
}

如果某处缺少支架，找到它会非常耗时！

Answer 10

良好的判断来自经验。

经验来自糟糕的判断。

这可能听起来过于简单，但我试着遵循这个口头禅。我尽量不犯同样的错误。

Answer 11

你是一个良好的开端 - 认识到你没有把它弄清楚。我们都没有。

确保您了解该域名 - 这将立即消除一些错误。知道你在解决什么，然后继续尝试开发解决方案。

有一个发展方法。我使用测试优先方法，但这不是唯一的方法。这为我提供了一个内置的检查器，我仍在使用它。我利用我的同伴来反弹想法，我之前使用过对编程并且发现了它的价值。

如果你开发了一个系统来减少'哑'的错误，你会发现它们会消失。也许一份清单可行。个人软件过程鼓励这种方法。试一试，看看它是否有效。

在我提交代码之前，我喜欢白板。我喜欢我的同龄人，告诉我为什么我的思维不正确。如果他们做不到，我有理由相信我已经消除了一些可能的障碍。

很多这将来自经验，主要是从做你做的事情和从你的错误中吸取教训！

Answer 12

始终保持“保持简单”的态度！如果你保持简单，你犯错误的机会就会减少。

RWendi

Answer 13

在完全理解问题之前，避免开始编写代码的冲动。如果您只了解问题的一部分，那么您可能会花时间重新设计设计。在脑海中或纸上清晰地了解大局，然后开始编码。

Answer 14

如果你不理解某些事情，不要害怕提问。我见过的大多数最大的错误都是由于某人不完全理解这一要求而没有提出进一步的问题以确保该计划正在实现预期目标。或者使用他们不理解的代码的人，不要求解释，然后不理解为什么它在特定情况下不起作用。然后有些人不能很好地理解他们的数据模型，以确定他们的查询是否返回正确的答案，它不足以运行，它需要返回正确的数据。同样，他们没有提出问题以获得更好的理解。我坐在会议中，看着人们点头表示赞同，并且知道他们只是从他们的肢体语言中做错了。但很难帮助那些不承认自己不理解的人。

Answer 15

我唯一尚未提及的建议，这对我有规律的帮助，就是：在我做出任何重大改变之前，无论是代码还是文档，我总是会在10-15分钟之前休息一下实际上最终确定了变化。通常休息时间会让我恢复精神 - 更重要的是 - 不会投入变化，而且我的大部分内容因此而变得非常明显。当你是唯一一个从事某项工作的人时，这通常会更有帮助，否则你可以获得通常优越的同行评审。

Answer 16

1. 不要害怕错误 - 这是学习新事物的最佳方式
2. 每周进行一次代码审核非常重要 - 与专家
3. 家中的代码 - 它将帮助您更快地提高自己
4. 阅读其他代码 - 开源代码是学习新事物的最佳方式

Answer 17

对我来说，当我盯着代码时，我会在一个方法中加入一种“待办事项”列表，详细说明我在每个阶段必须完成的工作才能完成工作。例如，如果我有一个获取客户名称的方法，我会写一些类似的东西。

public string GetName（int custID）         {

        // Create local variables

        // Get the connection string from the config file

        // Create Try Catch Finally block

        // Create SQL parameters 

        .... etc

    }

我不会将这些留在评论中，但会在我完成任务时删除它们。我不再这样做了，说实话，我怀疑你需要做太长时间。

另外，我建议如果你正在尝试学习一些新的东西，你做一个“真正的”项目，而不仅仅是书籍或网站上的例子（即使它只是一个小应用程序，让它自己工作） 。阅读一本关于代码的书并不能替代陷入困境。

Answer 18

一般来说，BIG错误来自潜水和编写软件之前的思考。我聘请了2名程序员，这就是我坚持他们所做的。它有很大的不同。

在纸上绘制您正在设计的屏幕，并在编码之前尽可能地确定其工作原理。向老板/客户/其他人展示。向他们解释。让他们批评它。

在您将代码视为UML之前，永远不要开始编写代码。 您不需要成为UML专家，但是类图表显示：

1. 继承
2. 聚合（例如，此网站由用户组成，用户发布多个帖子，帖子可以有其他用户的多条评论）

根本不考虑它会产生巨大的影响。

保持你的功能小 - 永远不要超过30行，通常更少。 这将有助于您构建代码。

Answer 19

评论很好。

很好地填补你的代码。

拥有有意义的变量名称。

Answer 20

我们都犯错误。天才就是那些只是把它们放在砧板上的人。

练习，频繁进行代码审查（我的意思是，经常），保留广泛的版本历史记录，并确保您知道在哪里可以找到能够更好地隐藏错误的人。 / p>

Answer 21

练习 - 你写的代码越多，你获得的经验就越多

重复使用代码 - 经常使用的代码最不可能包含缺陷

防御性编码 - 最大限度地减少风险代码的创建，避免边缘条件影响

测试 - 查看TDD单元测试（不是传统的单元测试） - 这意味着记录预期的代码行为并创建测试它的代码。更多代码意味着更多的经验，更自动化，更高的信心

Answer 22

静态分析工具非常有用。 Findbugs还提供有关特定做法对您的计划有害的原因的信息。

Answer 23

这里的大部分答案都相当普遍，但在开发代码时，您可以采取一些实际操作来减少错误。确切地说，它们在不同语言之间会有所不同，但是例如，如果语句中有一个常见的错误来源 - 很多语言并不坚持你将代码括在一个单行 - 例如。

if fred==bill dosomethingtofred() else dosomethingtobill();

这通常会导致错误 - 特别是如果稍后编辑代码。我还没有在这里将测试括起来，这在某些语言中是允许的，并且是潜在的错误生成器。我自己总是，毫无例外地构建一个完整的if语句，例如。

if (fred==bill) {
  dosomethingtobill();
}
else {
  dosomethingtofred();
}

（请注意，我个人更喜欢行尾{。有些人对它不屑一顾，在合作环境中使用新的线条样式可能更好，但我作为顾问主要编写代码，由我自己和我维护严格遵守缩进标准，因此代码的额外紧凑性得到了回报）

类似的技术可以在大多数语言中应用于各种代码结构。我建议你仔细检查你犯了什么愚蠢的错误然后考虑什么代码结构会阻止你这样做，然后每次都使用它们。我自己有这么多年构建的相当广泛的构造（另一个例子我所有的sql都以相同的方式布局）。除了减少愚蠢的错误，这还有一个额外的好处，我可以在几年后回到代码并快速获取功能。

Answer 24

尽你所能去理解你的错误。写下出错的地方，你试图解决错误的一切，以及最终有效的方法。我用这种方法强迫自己减速并盲目猜测。如果你这样做的时间足够长，你就会养成一种注重细节的工作习惯，这样可以减少你的错误。

Answer 25

我相信一件简单的事情。

代码一次，代码正确。

为了得到它（对我来说无论如何），我需要在做任何事情之前在心理上完全想象这个问题。如果我不完全理解问题，我会非常犹豫继续。

那就是说，有时你必须越过界限，只是看不到另一边的什么。

Answer 26

我们都犯了愚蠢的错误，因为我们是人。

我是一个新手，但我和一些经验丰富的专业人士合作过，他们犯了同样的愚蠢错误。这些是您将从中学到的错误，几乎可以立即纠正。

除此之外，我建议的最好的事情是在你编写的每一小段代码之后检查错误。当你每小时可以生成数百行代码时感觉很棒，但是当你有一千个错误和一千行需要检查时，你很快就会崩溃。