代码错误代码_如何使您的代码错误免费

代码错误代码

In the summer of 2015, a team of hackers attempted to take control of an unmanned highly classified military helicopter known as “Little Bird”.

2015年夏天，一群黑客试图控制一架被称为“小鸟”的无人高度机密军用直升机。

The hackers had a head start and within a short period of time, they had already hacked their way into one part of the drone’s computer system. From there, all they needed to do was hack into Little Bird’s onboard flight-control computer, and the drone was theirs. But they failed and the reason was a new kind of security mechanism implemented by DARPA (Defence Advanced Research Projects Agency) called the “formal or mathematical verification”.

黑客抢先一步，在很短的时间内，他们已经侵入了无人机计算机系统的一部分。 从那里，他们所需要做的就是入侵Little Bird的机载飞行控制计算机，而无人机正是他们的。 但是它们失败了，其原因是由DARPA(国防高级研究计划局)实施的一种新型安全机制，称为“形式或数学验证”。

In this mechanism, key parts of Little Bird’s computer system were made unhackable with existing technology and its code was made 100% foolproof just like as a mathematical proof. And unlike most computer code which is tested after getting written, formally verified software reads like a mathematical proof. Each statement follows logically from the preceding one. An entire program can be tested with the same certainty that mathematicians prove theorems.

在这种机制下，小鸟计算机系统的关键部分无法使用现有技术进行黑客攻击，并且其代码就像数学证明一样，具有100％的万无一失。 与大多数在编写代码后进行测试的计算机代码不同，经过正式验证的软件的读取就像数学证明。 每个语句在逻辑上都跟在前一个之后。 可以像数学家证明定理一样确定地测试整个程序。

As Kathleen Fisher, the founding program manager of the High-Assurance Cyber Military Systems (HACMS) project rightly says later.

正如高保障网络军事系统(HACMS)项目的创始项目经理Kathleen Fisher稍后正确地说的那样。

“They were not able to break out and disrupt the operation in any way. That result made all of DARPA stand up and say, oh my goodness, we can actually use this technology in systems we care about.”

“ 他们无法爆发并以任何方式破坏行动。 这个结果使所有DARPA站起来，说，哦，我的天哪，我们实际上可以在我们关心的系统中使用该技术。”

In a nutshell, the only way to have a 100% bug-free code is to mathematically prove the code. Very few programs in the world are mathematically proved, simply because it is way too expensive to be used. Most of us are working on projects that cannot justify the cost of mathematical proof and that is why we need to rely on our local bag of tricks to maintain the bug rate as low as possible.

简而言之，拥有100％无错误的代码的唯一方法是对代码进行数学证明。 世界上很少有程序在数学上得到证明，这仅仅是因为它太昂贵而无法使用。 我们大多数人都在进行无法证明数学证明成本合理的项目，这就是为什么我们需要依靠本地的技巧来将错误率保持在最低水平的原因。

That said, we can still write bug-free code and what I mean by bug-free code is writing software with acceptable quality, developed within the given cost and time. Our goal here is to minimize the bugs by making cheaper mistakes in order to avoid making more expensive ones. This way we can attain a reasonable level of perfection that justifies the investment of the project.

也就是说，我们仍然可以编写无错误的代码，而我的无错误代码是指在给定的成本和时间内开发出质量合格的软件。 我们的目标是通过减少错误，以减少错误，从而避免增加错误。 这样，我们可以达到合理的完美水平，证明该项目的投资合理。

And here are some ways to do so.

这是一些这样做的方法。

不要忽略警告 (Don’t ignore warnings)

When I was new to programming, I used to build applications, and in most cases, warnings used to spew out in droves. And when I used to ask fellow programmers about it, they simply told me to ignore them as warnings are harmless.

刚接触编程时，我曾经构建应用程序，并且在大多数情况下，警告大量涌入。 当我以前向程序员询问这个问题时，他们只是告诉我忽略它们，因为警告是无害的。

Really? Are they really harmless? I learned it the hard way and came to realize that eliminating the warnings always led to fewer bugs and less brittle code. Warnings are simply errors waiting to occur so ignoring them is dangerous for the following reasons.

真？ 他们真的无害吗？ 我很艰难地了解了这一点，并逐渐意识到，消除警告总是导致更少的错误和更少的易碎代码。 警告只是等待发生的错误，因此由于以下原因而忽略它们是危险的。

· Warnings are mostly default behavior of your compiler tool which might not suit your coding scenario.

·警告主要是编译器工具的默认行为，可能不适合您的编码方案。

· As warnings accumulate, bugs become harder to fix and prevent as the code may soon get out of control.

·随着警告的累积，错误变得更加难以修复和预防，因为代码可能很快就会失控。

· Abundant warnings mean a lack of team discipline. It shows that the coding standards are sloppy.

·大量警告意味着缺乏团队纪律。 它表明编码标准是草率的。

· The team may get into the habit of suppressing all warnings and this may also result in harmful warnings getting suppressed.

·团队可能养成抑制所有警告的习惯，这也可能导致有害警告被抑制。

Although it takes more time to fix a warning than to suppress it, it is a time well spent and will result in a cleaner, better code in the future. To expose potential bugs, set the warning level of the compiler tool to maximum strictness. Don’t tolerate warnings, eliminate them.

尽管修复警告要花费比抑制警告更多的时间，但是这是花费的时间，并且将来会导致代码更干净，更好。 要暴露潜在的错误，请将编译器工具的警告级别设置为最高严格度。 不要容忍警告，消除警告。

做自动化测试 (Do test automation)

Test automation increases overall software efficiency and ensures robust software quality. There are specific tools that can effectively execute automated test cases, and help in comparing actual and expected results.

测试自动化可提高整体软件效率，并确保强大的软件质量。 有一些特定的工具可以有效地执行自动化测试用例，并有助于比较实际结果和预期结果。

Some of the benefits of test automation can be.

测试自动化可以带来一些好处。

Faster Feedback: It improves communication among coders, designers, and product owners, and allows potential glitches to be immediately rectified.

更快的反馈：它改善了编码人员，设计人员和产品所有者之间的沟通，并允许立即纠正潜在的故障。

Accelerated Results: Testing can be carried out repeatedly, delivering faster results each time with lesser effort and time.

加快结果：可以重复进行测试，每次以更少的精力和时间获得更快的结果。

Testing Efficiency Improvement: Automated tests eventually take up a significantly lesser amount of time. They can be run virtually unattended, leaving the results to be monitored towards the end of the process.

测试效率的提高 ：自动化测试最终将花费更少的时间。 它们几乎可以在无人值守的情况下运行，从而可以在过程结束时对结果进行监视。

Higher Overall Test Coverage: Automated testing results in more number of tests being executed pertaining to an application. This leads to higher coverage than in a manual testing approach.

更高的总体测试覆盖率：自动化的测试导致执行与应用程序有关的更多测试。 与手动测试方法相比，这导致更高的覆盖率。

Earlier Detection of Defects: Defects getting detected earlier helps increase the overall development speed while ensuring correct functionality across areas. The earlier a defect is identified, the more cost-effective it is to fix the glitch.

尽早发现缺陷：尽早发现缺陷有助于提高总体开发速度，同时确保跨区域的正确功能。 越早发现缺陷，修复故障的成本效益就越高。

Remember having a solid battery of automated tests is an excellent way to decrease the bug rate and also to avoid new bugs while refactoring of code. The initial investment might be high, but the cost justifies the effort saved later in the project.

记住，拥有大量的自动化测试是降低错误率并避免在重构代码时避免出现新错误的绝妙方法。 最初的投资可能很高，但是成本证明了项目后期节省的精力是合理的。

管理程序输入 (Manage program inputs)

We all know the age-old adage “garbage in, garbage out”. So if your inputs are trash, you are bound to get bugs.

我们都知道古老的格言“ 垃圾进，垃圾出 ”。 因此，如果您输入的内容是垃圾，那么您肯定会遇到错误。

And all programs need to get data from external sources which might be unreliable or questionable. The source can be a user interface, a file, an external system, or even a database. For example, you expect a credit card number as an input and somebody enters SSN no. You expect US postal code to be entered and somebody enters postal code in Indian format. The possibilities of error are endless.

并且所有程序都需要从可能不可靠或有问题的外部来源获取数据。 源可以是用户界面，文件，外部系统甚至数据库。 例如，您希望输入信用卡号，然后有人输入SSN号。 您希望输入美国邮政编码，并且有人以印度格式输入邮政编码。 错误的可能性是无限的。

To make your program robust, you must validate every input to your program. I know validation increases program size and reduces the performance so it is important to do a trade-off very carefully between what is the “minimum” which can be accepted and what is absolutely “non-negotiable”.

为了使程序健壮，必须验证程序的每个输入。 我知道验证会增加程序大小并降低性能，因此非常谨慎地在可以接受的“ 最小 ”和绝对“ 不可协商 ”之间进行权衡非常重要。

And while validating you must make sure that you validate all the data at only one place, the point where your program obtains the inputs. By putting all the validations in one place, you can check for invalid data in an organized way and there will be no need to do data validation at other places.

并且在验证时，必须确保仅在一个位置(程序获取输入的位置)验证所有数据。 通过将所有验证放在一个位置，您可以有组织地检查无效数据，而无需在其他位置进行数据验证。

Remember managing program inputs is a very obvious but often overlooked technique for managing bugs. But it’s important and cannot be underestimated.

请记住，管理程序输入是一种非常明显但经常被忽略的用于管理错误的技术。 但这很重要，不能低估。

减少条件逻辑 (Reduce conditional logic)

I recently saw a ted talk by Miško Hevery in which he proposed an interesting challenge to his audience. He wanted them to write some code with no if-else or switch blocks at all.

最近，我看到了MiškoHevery的一次演讲 ，他向听众提出了一个有趣的挑战。 他希望他们写一些根本没有if-else或switch块的代码。

Is it even possible? The conditional logic building is the heart of any programming logic and what can possibly be gained by such an exercise? Hevery later explains that as the number of conditional statement increase, testing each combination becomes impossible and bugs start seeping in from unconceivable scenarios. Also too much conditional logic makes the program harder to understand and rectify.

可能吗？ 条件逻辑的建立是任何编程逻辑的核心，这样的练习可能会带来什么？ 稍后，Hevery会解释说，随着条件语句数量的增加，无法测试每种组合，并且错误会从难以想象的场景中渗入。 另外，太多的条件逻辑会使程序更难于理解和纠正。

Hevery’s point is that code without if (or switch) statements is

关键是没有if(或switch)语句的代码是

· Easier to read and understand

·易于阅读和理解

· Easier to test

·更容易测试

· Easier to maintain, extend, etc.

·易于维护，扩展等

While he agrees, complete elimination of conditional logic is unavoidable, but we can reduce the amount of it by using the following schemes.

尽管他同意，但不可避免地要完全消除条件逻辑，但是我们可以使用以下方案来减少条件逻辑的数量。

· Good OO design can eliminate the need to explicitly code branching.

·好的OO设计可以消除对显式代码分支的需求。

· Using assertions for validity checks.

·使用断言进行有效性检查。

· Using context and polymorphism.

·使用上下文和多态性。

· Eliminating train wreck code — A train wreck is multiple levels of method calls (called a chain), which each code calls a method on the return value of another method call. This deeply nested model goes against the Law of Demeter which is a design guideline to promote loose coupling of data structures that are not closely related, and thus should probably not be coupled together.

·消除火车残骸代码—火车残骸是多个级别的方法调用( 称为链 )，每个代码都在另一个方法调用的返回值上调用一个方法。 这种深层嵌套的模型违背了Demeter法则，该法则是设计指南，旨在促进不紧密相关的数据结构的松散耦合，因此可能不应该耦合在一起。

Remember less is more. The more code you write into production, the more you’re going to need to maintain it, and the more skeptical you should be about how readable and bug-free it really is.

记住少即是多。 您在生产中编写的代码越多，维护它所需要的越多，并且对它的可读性和无缺陷性应该抱有更大的怀疑。

最后，听听用户 (Lastly, listen to the user)

Yes. By users, I mean real users who will be using the application and not testers who certified your code.

是。 对于用户，我指的是将使用该应用程序的真实用户，而不是认证您代码的测试人员。

You might argue here.” The tester certified my code. Why should I bother?” Wrong. You are responsible to deliver correct code that will satisfy users and you need to infer statistics from their feedbacks to assess the stability or instability of your code.

您可能会在这里争论。” 测试人员证明了我的代码。 我为什么要打扰？” 错误。 您有责任提供使用户满意的正确代码，并且需要从他们的反馈中推断出统计信息，以评估代码的稳定性或不稳定性。

That said, most bugs are a result of either modified code or new code. It is very rare to find a bug in an already stable code that is working well in production. But it does happen at times.

也就是说，大多数错误是由于修改代码或新代码而导致的。 在已经可以在生产中正常运行的稳定代码中找到错误的情况很少见。 但是它确实有时会发生。

And how do you know that some code works well for a long time in production? Simply by listening to users. If they didn’t report problems on some features for a long time, then you can be confident that the underlying code is stable.

您怎么知道某些代码可以长期在生产环境中正常工作？ 只需通过听用户。 如果他们很长时间没有报告某些功能上的问题，那么您可以确信底层代码是稳定的。

Remember real users will complain when they will find a bug and they will remain silent when they consider that the product is working fine. This can be your litmus test as a developer to improve yourself after every such feedback. Some of the most valuable feedback can also be used to address.

请记住，真正的用户在发现错误时会抱怨，并且在认为产品运行正常时会保持沉默。 这可能是您作为开发人员改善自己后得到的反馈的试金石。 一些最有价值的反馈也可以用来解决。

· Functional issues in code.

·代码中的功能性问题。

· Missing validation and corner cases

·缺少验证和特殊情况

· API usage and design patterns

·API使用和设计模式

And so on….

等等…。

Finally, nothing in this world is perfect, including software. It requires rigorous testing before launch and constant updates after launch to stay relevant and ensure good user experience. Even after a software is released, you cannot control its execution environment because there are many devices it can run on and conditions of failure can happen anywhere, anytime. Don’t fret over it.

最后，这个世界上没有什么是完美的，包括软件。 它需要在发布前进行严格的测试，并在发布后进行不断的更新以保持相关性并确保良好的用户体验。 即使发布了软件，也无法控制其执行环境，因为它可以在许多设备上运行，并且故障条件随时随地都可能发生。 不要担心。

Your best bet is to strive for excellence, not perfection, and realize that you’re not going to achieve bug-free development unless you’re building a space shuttle. Excellence focuses your attention on what is right and working rather than on what is not working. Excellence is limitless, progressive, and is the best way to go into the continual improvement mode.

最好的选择是追求卓越而不是完美，并意识到除非建造航天飞机，否则您将无法实现无错误的开发。 卓越将您的注意力集中在正确和有效的事情上，而不是无效的事情上。 卓越是无限，进步的，是进入持续改进模式的最佳方法。

About the author-:

关于作者-：

Mythili is a programmer by passion and a connoisseur of fine arts like painting, calligraphy, and pottery. She writes in the twilight between relationships, creativity, and human behavior.

Mythili是一位热情的程序员，是绘画，书法和陶艺等美术的鉴赏家。 她在关系，创造力和人类行为之间的暮色中写作。

翻译自: https://medium.com/dev-genius/how-to-make-your-code-bug-free-95014c4a07d7

代码错误代码