今日推荐英文原文：《In Code We Trust》
今日推荐英文原文：《In Code We Trust》作者：Ryan Nehring
In Code We Trust
Test more, it mattersDespite our best efforts, we programmers remain imperfect beings. Time constraints, misunderstood problem sets, limited testing, and technology conflicts all contribute to mistakes in the applications we build.
In the best cases, these mistakes manifest as minor annoyances to the user. In more severe cases, they can render our programs unusable. In either of these cases, the problem is visible and readily apparent and can be corrected through revision.
There is a much more dangerous type of mistake, however, with the potential to cause severe harm under certain conditions; the systemic failure.
Systemic failures in code are mistakes made in the logic or algorithm of the application. These mistakes happen silently and produce outputs that are incorrect but present as accurate.
Users trust our systems. When they click a button to find out their profit for a month in their accounting software, they expect and trust that the result is correct.
A mistake in that calculation could be disastrous to a small business owner. They may take on more inventory or pay a bill early with the mistaken belief that they have more cash on hand than they do.
In an even more extreme example, consider the software that runs inside of hospitals. We are programmers, not health care professionals, so our inherent understanding of the variables at play is limited. That’s incredibly dangerous.
Seemingly minor code mistakes, like mixing up a user ID or having a database transaction fail, could result in a patient getting the wrong medication, the wrong treatment, or being fed something they’re allergic to. It’s not too hyperbolic to say that lives are literally on the line.
Trust but VerifyAs programmers, we have a responsibility to ensure our code functions as advertised. Far too often, if our code compiles or executes and produces output, we assume it’s correct.
If nothing blinks or beeps or flashes, then we’re satisfied that we’ve solved the problem.
I suspect this stems from our logical natures. We tend to have faith in the logical parts of the systems we build, and consider the UI and connecting threads to be little more than the supporting cast, so we rarely double-check that logic.
We must verify that all the parts of the applications we build are functioning correctly, not just the parts we see.
TestingTesting is an integral part of the development process and one that is short-changed far too often. Time spent testing should be commensurate with the complexity of the program you’re building, and expand from there, depending on the stakes at hand.
It’s probably not worth spending three months testing your form processor script to ensure no one ever enters a bad email address, but if your program has to calculate insulin dosages you better keep testing until you’re absolutely sure it’s correct.
I don’t just mean running the program over and over either. When the calculations are critically important, I frequently revert to pen and paper and run some numbers by hand to be positive I have the formula perfect.
Be TrustworthyUltimately, users are going to trust your applications in most cases. It’s in our nature and software has become so ubiquitous to daily life that most people rarely give its accuracy a second thought.
It is incumbent upon us as programmers to be worthy of that trust, especially in instances where the results have real-world consequences, and that means — testing.
Lots and lots of, often mind-numbing, repetitive testing.
Be diligent and mindful in your process and your projects will benefit from it, in all cases. Form these habits now and you’ll enjoy the added benefit of fewer refactors and code revisions, as well as happier users who love your application.