Archive for the ‘Popular’ Category
1.- DRY: Don’t repeat yourself.
DRY is usually the easiest principle to understand, but it is quite harder to apply. It means that when finding similar code in two or more places, we should abstract them into a new method and change the previous code fragments so they will now call the new method with the appropriate parameters.
DRY is maybe the most universal coding principle, I have never found a developer who would argue that repeating code is good, but, I have found developers that forget about this principle when coding unit tests, as an example: imagine that you have changed the interface of a class which had lots of unit tests, if you haven’t used DRY, you will have to manually change the call to this class interface to match the new signatures to each test case.
2.- Write short methods.
There are three very good reasons for writing short methods.
- Your code will be easier to read.
- Your code will be easier to reuse (short methods are likely to produce loose coupling).
- Your code will be easier to test.
3.- Use good names for your classes, methods and variables.
There is nothing nicer than using some other developer code and not having to read its documentation because the names of the classes and the methods are telling us everything, so, make everyone’s life easier and take this approach, expend always a few seconds before naming any element in your code.
4.- Assign the right responsibility to each class.
One class, one responsibility, that will sound familiar to those who know about the SOLID principles, but not any responsibility, the right responsibility, so if we have the class Customer, we won’t assign to it the responsibility to create a new sales action, we will just assign it the responsibility to handle all the data related with a customer.
5.- Keep your code organized.
This organization is at two levels.
- Physical organization: Whatever the structure you are using, packages, namespaces, folders… Organize your classes in such a way that is easy and intuitive to find where the code is stored.
- Logical organization: Whatever belongs logically together should have access to each other members, but what belongs to a different logic structure has to access them by an interface. These logic groups are commonly implemented as layers, services…
6.- Create lots of unit tests.
The most tests you have, the better, they are our safety net for all the changes we will have to perform in the code in the future.
7.- Refactor often and sooner.
Software development is a continuous discovery process, in order to keep up to date with good code that matches the new/changing requirements is essential to refactor the code as we go. As this is a risky task there are 2 main preconditions to avoid entering new bugs into the system.
- Have lots of unit tests.
- Do small refactor steps at a time. In software development there are very few things more annoying than start refactoring 2000 lines of code to after 3 hours of work realize that is necessary to roll back to the original version because now nothing works and the track of which change is causing the problem is lost.
8.- Comments are evil.
This particular one is a bit controversial, most of us were taught that comments are good, and actually it’s better to have a comment in an obscure piece of code than just having the code by itself, what this point means is that: even better than having a comment for an obscure piece of code is to not to have that code at all, just refactor it until is a nice and readable piece of code. [EDIT] Please read this other post for a better explanation of what “comments are evil” means.
9.- Code to an interface, not to an implementation.
This is a classic one, coding to an interface will free us from the implementation details, we just define a contract and rely on calling the defined operations on the contract, expecting that the actual implementation will be passed to our code or decided at runtime.
10.- Have code reviews.
We all make mistakes, and there’s nothing better than asking some other person to have a quick and informal review in our code to find them, in order to make the reviews, it’s better not to wait until the code is completed, it’s better to ask for reviews whenever some important part of the code has been completed or when a few days have passed from the previous review.
There are many articles on Internet with tips on how to become a better developer, most of them focus on promoting learning attitudes like reading articles, books…
- Ryan Farley – Becoming a Better Developer
- Bil Simser – Being a Better Developer… in 6 months
- Justice Gray – How I am becoming a better developer, part 1 of infinity
- Rodrigo Diaz – How to be a better developer?
In this article I want to approach this subject from a different perspective I am going to present a few unusual tips which I believe will help you to become a better developer.
Be adaptable to any work environment (there is no “I” in team)
You may be a convinced agile practitioner or a waterfall one, but in the team where you are working they are not. Or you may be in a design session where you don’t agree with what has been decided…
You will always face conflicts, a good developer will know when it’s time for discussion and when it’s time to stick with the team and do as best as possible. The worst dynamic for a team, it’s when the people are not aligned in the same direction. (article from Jeff Atwood – codinghorror.com about this issue) .
This means that when a decision has been made you shouldn’t use every opportunity, every meeting, to remind your colleagues how wrong you think they are, you will be just mining the team confidence. One of the worst aspects I have observed from software developers is their ego, I’ve seen many times how attitudes like “If it’s not my way, no way” gets in the middle of getting things done.
This doesn’t mean that you don’t have to fight for your opinions and ideas, there is a time to make decisions and that’s when you have to bring all your ideas, after a decision is made, embrace it as if it was your decision, if you can’t is better that you just talk with your manager and you leave that team.
This doesn’t mean either that you have to give up if you see that the team goes in the wrong direction just because a decision has been already made, wait to have evidence that the team’s direction is not the right one, think on how to improve it and show it to your colleagues with a positive attitude
Understand that most of the times everyone is wrong
Drop the attitude “I’m right, You’re not”, both of you are wrong. In the software development industry I’ve seen very few times situations where someone holds all the truth about something, is very likely that in a software discussion all the parts involved are just partially right, a good software developer has to be able to recognize what can be bundle from everyone’s opinions in order to come up with the best possible solution.
Don’t get stressed. Enjoy what you are doing.
I keep reading articles about telling developers to read blogs, books, to code in your spare time, to write your own posts… And it’s not that I don’t think that it won’t help you to be a better software developer, of course it will, but it can also be really bad for you.
I actually wrote an article about how passion is the main difference between a good software developer and an average software developer, but if that passion is pushing you to the point where you are getting stressed, just take one step back.
- If you are not enjoying it, why are you doing it?
- If you are not enjoying it, you will eventually quit.