“It takes less time to do something good than to explain why you did it wrong.” – HV Longfellow
Since my first encounter with tasks and implementation, while I still studied, to this day, my view of programming and code organization has changed drastically. Initially, just as to any other junior, it was important to me to put together a code, whatever type of it, it was only important to do what was required. It was completely irrelevant how many methods I would implement, how many code lines I would type and what performances it would have. Then, in time, you start maintaining that spaghetti code after one year of break. Business logic has been forgotten, and there are no comments in the code. The code is not at all descriptive, and there are some nonsense written. You are grabbing your head and commenting: “Who is the Indians who hammered this? Upsss, me! “. Torment follows the torment and there is no light at the end of the tunnel to be seen. Anyone who has maintained at least one project in production knows about the suffering I am talking about.
The code you used to boast with suddenly becomes the code because of which you pull the hair on your head, provided that there is still some hair left. Then, taught by this experience, you embark a new project and try not to repeat the same mistakes, but to upgrade everything and raise it to a higher level. All that aiming to avoid headaches that might occur when after a while you look at your code. At that moment, it is no longer important for the code to be functional, but also to be legible and maintainable. You begin to refactor your code and see that some things can be written in a simpler and better way.
In order to learn more and improve my knowledge, I watched various video tutorials and read numerous blogs, both our own and those of foreign programmers. In the beginning, I started with basic things. I tried to stick by the Single Responsibility method and class. The method should do only one thing. No more getAndUpdate or saveOrChange, but only get, find, validate…. Also, I tried to put all private methods to the end of the class, i.e. after the public methods. When you name the methods, feel free to give yourself freedom and write descriptively the name of that method. So you know what this method does when you read its name, and not getAndUpdate. What to get and update of what? This means that you have to look at the method itself to grasp what the writer wanted to say. Do not worry, I will not bother you and bore you with bad smells, but it’s not a waste of time to mention it. Maybe in another blog.
At places where you think it is necessary, feel free to comment. It wouldn’t do you any harm if you describe why this method works in exactly that way. Maybe tomorrow, you save yourself or your colleague a lot of time and you will not have to torture yourself and invent hot water. All of us, younger developers (well, I’m not very young and have a couple of gray hair), we are resorting to quick solutions in order to show our productivity and show ourselves in a better light, and we do not even suspect that such bad code will come to payment sooner or later.
Try not to duplicate the code, but extract this code into a particular class/method, and use that further wherever possible. Most developers particularly enjoy doing the “copy-paste” of the code. These are the first things you should try to get rid of. How do you know the code that you copied is good?
Hello guy, process that exception properly. There is, for example, BusinessException or SystemException. You do not have to use Exception every time. You cling desperately to that class.
Remember that You are the most important project that you will work on!
Start upgrading your code from tiny and basic things. Try to work on yourself and your code constantly. Use every new project to experiment with something new and to improve the existing approaches. If in each new project you upgrade at least one thing in your programming, you will advance a lot, without even being aware of that. You will become aware of that only when the complex situation is repeated, and your code and you are ready to respond to each client’s request in just a few lines of a code, because you have previously optimized and organized the project well. Try in your work to observe a wider picture, and not just the part you need for your task. This part of the blog is ideal to use a “think out of the box” thing.
I do not know whether you are working as a freelancer or you are a part of a development team, but try to practice Code Review. It helps me a lot to improve my knowledge and correct some of the mistakes that I occasionally make. Consult your colleagues and listen to smart things they have to say. You may catch a trick that is going to be very useful to you and use it at the right time to get out of complex situations. It’s not bad to have some Hello World project at home, which will serve you to type and play with new approaches. We are fortunate to be involved in a job that is very interesting and brings new and interesting problems for resolving on a daily basis. It would be a pity not to use this wideness and freedom in approach and resolving of problems that this job offers.
Method should not be longer than a bottle of beer
For all those who want to scratch a little more below the surface when it comes to code purity, I advise you to take a glance of the video tutorials of Uncle Bob titled Clean Coders while making the break from watching the Avenger, or Star Wars. I was recommended that by one of my little older colleagues and I am very grateful to him. If you, dear reader and frustrated programmer’s soul,have some suggestions for quality reading on this subject, find me on LinkedIn and feel free to toss me a link. I’ll be grateful.
You think this is just an empty talk? Do you keep your hygiene? I hope you have a regular bath, brush your teeth … Why not keeping the hygiene of the code? I did not invent hot water here, nor did I talk about things that were new, but very possibly I mentioned something that you did not pay attention to at first. I will be glad if at least one developing martyr, after this scribbling of mine, leaves and erases the Literal String from the code.
Do not be lazy and do not find it too hard to correct some omission once you spot it, even when that code is functional. If you don’t have enough time, put TODO or FIXME, then return to it when the opportunity arises. Be careful and do not take refactoring too easily. Especially if you have a test team that will have to re-test something that is closed and delivered. Any code, no matter how good it is written, can do even better! Do not rush and take care of what you do…
The topic that I have opened up is very extensive and I would not like to continue boring you. I believe that you have already begun to yawn. My goal was to make younger generations, and especially those who have just been employed pay a little more attention to the things they do not pay enough attention to right now, through a certain amount of humor. If I succeeded in motivating someone at least a little bit the scribbling of this text had a purpose.
Until the next scribbling,