How to avoid errors and not miss anything [duplicate]

Question

I have a problem that is more serious than it might seem.

I've been programming for about three years , and I have learned and improved a lot , I read the code easily to others, understand the problems and transform them into code, I easily adapt to new technology and I love to learn how it all works . That's all fine .

The problem I have is that I often forget small details , which then turn out to be critical . For instance , yesterday, after changing a database query to retrieve some data filtering by twenty fields , forgot to load all the data ( the query returned only the data of the primary key of the whole object ) . Other times are smaller things that do not make the whole process fails, but still I am afraid to fail at something serious , that my superiors grow weary of my mistakes , etc. .

I would like to know how I can schedule the job to not forget anything or at least soon realize that I have forgotten something or have missed something ...

Answer 1

I would like to know how I can schedule the job to not forget anything

You can't. Whether you're Robin Seggelmann or Donald Knuth, writing a computer program of any realistic size is simply not a task that the human mind can achieve wholly without errors. That's a simple truth, it's just often ignored because the mind has a fantastically advanced capability of overestimating its own powers. In fact, it usually assumes that it is infallible, but it virtually never is.

or at least soon realize that I have forgotten something or have missed something

That's what testing is for. Testing is not a disgrace, it's a normal and expected part of development. (It's debugging that is a disgrace, because having to debug indicates that you wrote code where you yourself don't understand how it works.)

Answer 2

Testing, testing, testing. Automated Tests. TDD. BDD.

Nearly all people commit mistakes (and some costly ** ahem **). Don't fear them, just learn from them when you do make mistakes. And test your code. Look at the possible places that it can fail (at the limits of the data, on special cases, ...) and create appropriate tests.

Answer 3

I'm not a senior programmer either, but I would say you'll have to test your code to be sure of what you wrote. You'll never avoid programming mistakes (we're all human beings), but you can try and test your code all the time.

Answer 4

As you certainly have understood, testing is the solution.

There are several things that could help you.

1. Creating automated tests. There are tools for that such as Junit for Java and Nunit or the built-in unit testing of Visual Studio for .Net. The more your code is covered by these tests, the better it will get. (There are tools for that, please Google it). These tests should be executed automatically when you build your application.
2. If you have time, create testing plans for integration testing and all the tests you cannot do automatically.
3. Track your bugs (there are tools for that, such as JIRA, Bugzilla, etc.) and NEVER forget to update your automated tests and test plans so you can detect eventual regressions.
4. More generally if your project allows its use Test Driven Development (TDD) which basically requires that you write your tests before implementing your functionality.

Note that these points should be implemented by your whole team. Maybe there is something to suggest to your team leader or to your project manager.

Answer 5

Programming is a bizarre activity. Compared to any other human activity, it is devoid of any innate feedback.

I often illustrate this by comparing our work to that of a bricklayer:

To become a skilled bricklayer takes time and practice. You need to develop a feel for the bricks, the mortar and the tools. One thing that helps in the physical world is that the activity of laying bricks is full of feedback.

You prepare the next layer of bricks by putting up a line (a length of string aligned with the top of the new layer). Then you drop down some mortar, the amount of which you can feel when lifting it out of its bucket. So, you can see where the next line of bricks go, and you can feel the right amount of mortar. When you put it down, you can hear how it drops, which again confirms the amount used, and if it was placed correctly.

Next, you can pick up the next brick, and sensing its weight, you know exactly how to move it and again you use your sight and touch to decide where to drop it. The moment it touches the mortar, you know how it drops in place.

Any deviations from the norm are automatically corrected, as you know immediately that things need to be adjusted. You don't have to think about it, as this becomes second nature.

So how would we develop this innate feedback in programming, when that visible and tactile feedback is not present?

The closest that we've gotten so far, as far as I can see, is to introduce this feedback with Test Driven Development, and coding together.

Working together on the same code will force you to serialize your thoughts into speech, into words. Writing failing tests first will give you confidence that you're writing sensible tests, that will help guide you towards a working solution.

Answer 6

One method that works for me is I keep a note of everything that comes into my mind when I'm coding. I don't let them distract me and just carry on what I am coding and then I review them all at the end.

For example, I'll get half way through writing some data processing code and I'll suddenly think "I hope I disposed that file reader properly". I make a quick note and carry on with the data processing code.

Otherwise I found that was was happening was I'd think "I hope I disposed that file reader properly", go to that bit of code, check it and fix if needed and then go back to the data processing code. By then I'd lost my train of thought with that and the data processing part would be buggy.

Try to keep a note of everything you need to think about, but don't get distracted from your current coding activity or you'll introduce more bugs.

Answer 7

• Code for the current set of requirements. Don't add any infrastructure for features that don't exist - they will complicate your code without delivering any immediate benefits. If you try to anticipate the future features, you'll probably be wrong anyways.
• Don't optimize anything until you've measured, confirmed you have a problem, profiled, and found the bottleneck.
• Avoid null like the plague. In fact, forbid it outright. It's a language flaw and a hole in the type system. Nothing good comes from using null.
• Avoid mutable state. This will be a challenge outside of functional programming languages, but you should strive for it to the degree that your language will make it practical. Don't automatically slap setters on your classes if you can trivially construct a new object with the right values. Don't use a mutable data structure if a persistent version is available.
• Make sure the behavior of any function or class you write is thoroughly and completely documented. (Writing small functions and classes that only do one thing will help a lot here.)
• Learn how to construct a proof. It doesn't have to be extremely formal.
• Get other people to review your code and proof (if any).
• Unit test your code religiously in case something was overlooked. Don't bother testing every little scenario here - it's not productive. This is a sanity check; test a small handful of cases that are likely to break or are particularly tricky.

Even after doing all that, don't forget Knuth's words:

Beware of bugs in the above code; I have only proved it correct, not tried it.