Over the past few years, I denoted the top mistakes young software developers make. Learning these three skills properly will help you to skyrocket your career and be more efficient at development.
You've probably heard of this. If you are a backend developer, chances are, you do it already.
But a lot of developers ignore the tdd approach or don't even write a single line of test code.
The main point I always hear is: my code works fine. Why should I write a test before (in other words: why tdd?) or why should I write one after?
Writing it before
Writing tests before the production code is handy for covering all the possible cases.
After some time for adaptation, you will see how your feature specifications will be much clearer and particular business logic will be encapsulated and atomically testable.
Writing it after
Not choosing the TDD approach is okay too. As long as you write the tests at least after the production code is done.
Why should I do it? I see it's working.
Yes! You see it, great! But the devil is hidden in the details. At the time you are writing your test, you won't see an issue with your code. Now, wait until somebody else, or even yourself touches the code in a few weeks.
Will you think about all the cases?
If not - do you want to test them all manually?
Do you think that you would understand how to use the snippets? Or would you go with copy-pasting a random snippet?
Tests do more than just lock a specific behavior. They document the code and force you to write testable code.
Design patterns and refactoring rules
As a professional developer, refactoring is not something, that you do on your gut feeling. There are several great rules designed by the GoF that you can apply in chronological and atomic order to make your code base reusable and maintainable.
I learned a lot of my software architectural knowledge from refactoring.guru.
Chances are, you are already using a lot of those patterns, but do not know how to name them. Whilst this is not important if you are working solo, it could be a very helpful step to learn the terminology to share with colleagues.
Naming is the hardest thing in software development. The better your understanding of English and the more precise you can express yourself, the easier to read your code will be.
I often see code like this
def create_book(u_id, p, t) result = user.where(enabled: true).find(id: user_id) Book.create(pages: p, title: t, author: result) end
This isn't even a really bad example of what I've seen over the years, but it's enough to prove my point.
Having great names for variables, methods and classes will make Code Comments unemployed.
Instead of taking the
create_book method and commenting, on what each parameter does, we could instead write it like this:
def create_book(author_id, pages, title) author = find_author_by_id(author_id) Book.create(pages: pages, title: title, author: author) end private def find_author_by_id(author_id) User.where(enabled: true).find(id: author_id) end
This way you don't even need a single line of commentary. Every line on its own is understandable and flows like an English sentence.
That's a wrap
Software development is a never-ending topic. My recommendation is to invest your time in being more efficient, by writing good code.
Learn how to name things properly, how to write unit tests, and the rules of refactoring. It will boost your career!