I’m pretty sure that you have in the past read some pieces of code that are not well done, or, at least, you had that impression. When you are reading a fragment of code for the first time, it is sometimes hard to understand because you are not the developer who wrote it, maybe you would have written that piece of code in a different way. But this does not mean that the code is not well done, the authors just used a different approach to what you would have used.
Even within the same team, in a team that has worked together for… let’s say a year, sometimes the same problem still occurs because we don’t all have the same skills and we can’t think in exactly the same manner, but it’s important to keep some consistency around the same code base.
Let’s say you have joined a new company, a new project. You’ve got the project’s code and at the beginning it’s hard to know where to start, what should be the initial point to look into the project when you have just joined? Should I look at the main entry point of the application? The architecture? The tests? Well, it depends. For me it should be the tests but only if those tests are self-explanatory and are written in a proper way. What is a proper way? Go to a test in your application, collapse in your IDE the body of the methods and try to read it without looking at the implementation. Is it clear enough for you to get the idea of your domain rules? If so, you are in the right path. Reading a test that is hard to understand and its intent is not clear is even worse that taking a look at the production code directly.
Let’s assume you have joined that project and the code is not as good as you would desire. How did you get to that conclusion? Why don’t you like that code? Is it because you don’t understand how it is structured and you have less experience than the people that wrote the code? or in the other hand is it because you are joining a team that has legacy code for which the people don’t care about? Can you write this piece of code better?
Analyzing the code
Alan Shalloway has suggested seven characteristics of quality code: cohesion, loose coupling, no redundancy, encapsulation, testability, readability, and focus. Does that code accomplish them? Are you able to recognize which characteristic is not present in your code? And more importantly, are you able to fix that code?
These code qualities can be found in the book The ThoughtWorks anthalogy which also proposes a series of 9 rules in order to accomplish them, they are called: Object calisthenics You might think that these rules are very extreme for everyday development, but I use them as an exercise to improve my coding skills so my code can fulfill the qualities mentioned before.
If a piece of software is actually working in production, in principle it’s not written with bad code as it is achieving one of the two main values of software. As described by Uncle Bob in one of his books, the secondary value of software is provided by code that accomplishes it’s behavior and the primary value is provided by well-crafted code. Software that does not achieve the primary value is in my opinion built with sad code, and it’s sad because when I read the code it makes me sad, it’s badly formatted, it has plenty of code smells, unused variables, it is code that you can’t test without resorting to tricks, etc…
Trying to fix sad code
To avoid sad code in your project, maybe you are thinking that the best way is to start testing a feature and refactor this feature to give it more love. But is this worth it if your team does not have the same morals as you do? Imagine that you refactor a feature today and within a week one of your team mates touches something in the code that you already re-factored and it starts to smell again.
Another kind of developers
We are all tired of this kind of situations, sometimes maybe it’s the team’s fault, another time maybe it’s because the business is expecting too many features and the team has so much pressure that the result is the same in the end, the code rots. There are some movements like the Software Craftmanship that say:
Not only working software, but also well-crafted software
Not only responding to change but also steadily adding value
Not only individuals and interactions, but also a community of professionals
Not only customer collaboration, but also productive partnerships
- I will not produce harmful code.
- The code that I produce will always be my best work. I will not knowingly release code that is defective either in behavior or structure.
- I will produce, with each release, a quick, sure, and repeatable proof that every element of the code works as it should.
- I will make frequent, small, releases so that I do not impede the progress of others.
- I will fearlessly and relentlessly improve the code at every opportunity. I will never make the code worse.
- I will do all that I can to keep the productivity of myself, and others, as high as possible. I will do nothing that decreases that productivity.
- I will continuously ensure that others can cover for me, and that I can cover for them.
- I will produce estimates that are honest both in magnitude and precision. I will not make promises without certainty.
- I will never stop learning and improving my craft.
These movements are about the same things, morality about our profession, professionalism and pragmatism. I would like to classify these commandments as 2 separate things taking advantage of the previous classification for software. The secondary value commandments are those related to the sector/industry of your company, so for example, if you work at a company that makes weapons, you are helping to make these things, it’s your moral that let you work for that company. On the other hand, we have the primary value commandments, which are those related with the code quality. I classified as secondary commandments those related with the morality because they are up to you, it’s something that you need to decide, but the code quality is something that us as developers can decide as a profession, together.
This is not about perfectionism
Some business guys accuse us of trying to code perfectly, but this is not about perfectionism. If you take a look at the craftsmanship manifesto they talk about adding value. But there is only a way to add value to your software and it is by writing code that while in the middle of building a feature it does not get corrupted, it is still readable and maintainable.
Motivate your team mates
If your teammates don’t care so much about code maybe it’s because they don’t know the art of writing well-crafted code yet. This is something that you don’t learn at your school, it’s something that you need to learn after your studies, so if you are really into these ideas, can you introduce these people to this awesome world? You can do the following for your teammates:
in your company, you should request one. This is the best way to learn together in a team, but to be effective you should be able to use constructive criticism.
What if all of the above does not work
Well, not all the companies have the same spirit, not every person think in the same manner, but you have a problem. You care about code, you are a professional, you’ve done what was in your hand to change this situation but, if you, unfortunately, could not change it, there is no other solution, you should change your job, you should get a job that offers you a project, a team, and values that you agree with.