Check out my books on Amazon at https://www.amazon.com/John-Au-Yeung/e/B08FT5NT62
Subscribe to my email list now at http://jauyeung.net/subscribe/
Writing software is hard. Therefore, there’re many ways that we can mess up.
However, if we’re aware of them, then we may think twice before doing the wrong thing.
In this article, we’ll look at some mistakes that many developers have made before.
Committing Code in the Wrong Branch
Committing code to the wrong branch is something that’s been done a lot.
Since we’re supposed to make a new branch for even making the smallest changes, we may do this a lot.
Worse yet, we force pushed the wrong branch and overwrite the commit history of a branch that we shouldn’t.
We definitely let that happen.
We can protect our branches that we can’t mess up on so that we won’t accidentally commit the wrong things to them.
Hacky Code
Hacks will bite us in the long run. Unless our code ios total throwaway code, we should think about the long term consequences of our hacks.
We may write crappy codes that are hard to read so that others can’t work on it.
Also, we may run into problems later when we try to change our code or when new change requests come in.
We shouldn’t write a hacky code for anything that is used for years.
This way, we won’t run into problems later on.
Code That’s Way Too Fancy
Code that’s too fancy is also a problem.
Anything over-engineered is bad. If we should make our code easy to changes, but we don’t have to incorporate everything in the get-go.
If we can keep our code simple, then we should keep them simple.
No code is a lot better than code that we don’t need.
Also, we don’t want to write code that’d overly clever. This way, we don’t have to make others read code that are hard to understand.
Hard to understand code is definitely not pleasant for anyone to read or work with.
Underestimating the Workload
We should always give generous estimates that give us plenty of time to do the work.
Therefore, we shouldn’t underestimate the workload that something takes to be complete.
If we underestimate, then we’ll disappoint people that are looking forward to our stuff after a short time.
We’ll also be under pressure to rush out our code, which isn’t good.
Assuming we Don’t Need to Test Your Code
Any small change can break something.
Therefore, we should make sure that we test our code no matter what we change.
Changes never end up like what we expect.
Therefore, we should always test our code so that they do what we expect.
We should write automated tests so that we can test faster.
Reinventing the Wheel
Reinventing the wheel isn’t good. It’ll slow us down and create duplicate code.
We don’t want that. If we can reuse something that’s already there, then we should do that.
This way, we work faster and we don’t have to write everything from scratch.
For instance, JavaScript arrays have lots of methods to make manipulating arrays easy.
Therefore, we should use them to manipulate arrays instead of using loops.
Reinventing the wheel is often because of ignorance.
Therefore, we should know the language, libraries, and frameworks well so that we won’t implement the same thing that are already available somewhere else.
Committing the Wrong Files
Committing the wrong files can also happen.
It happens easier if we don’t see what we’re committing graphically like when we commit our code with the command line.
Therefore, it may be a good idea to visualize what we’re committing by using a graphical client for the version control systems that we’re using so that we can see what we’re committing clearer.
Code is Never Self-Documenting
Some code may need explaining. Even if we know the workflow from the code, we can still use comments to justify decisions and tell people why something is done the way it is.
Writing comments that explain why will help everyone know the code better.
As long as we aren’t just repeating the code what the code says in our comments, we should leave some comments.
Conclusion
To avoid mistakes, we should learn more so that we don’t reinvent the wheel.
We can avoid branching and commit mistakes by protecting branches and using a graphical version control client.
Hacky code will always come back to bite us later. Unless we write throwaway code, we should think about that.
Finally, we may want to leave some comments to explain our decisions in our code.
Top comments (0)