Reading and Learning 'Clean Code' by Uncle Bob #Day_2
Understand clean code with me and become the clean coder
On Day 1, I covered the introduction part to the books I'm reading these days on clean code and the clean coder. If you haven't checked out day 1, I would recommend you to do so because this journey is about styles, techniques and mindset, it works like the stack data structure. One pushed on the other. And today I wanna jump right into discussing some of the techniques to write clean code. I'll present my interpretation of those techniques, would make an attempt to explain the reasoning behind it and I might use obnoxious jokes as fillers.
Before I start, remember what you read on day 1, set your thoughts and then move forward and try to analyze these suggestions and techniques from the book.
Hey Everyone, I'm Aqsa Shoeb and I'm currently reading 'Clean Code' by Robert C. Martin and here's what I like to share:
Chapter 1: Clean Code
Following points sum up this chapter for me.
There's gonna be code at every point of time. Code is the language in which we express our requirements. The necessary precision can never be eliminated so there will always be the need to write code, clean code.
Rushing for the market and messing code for that may turn out successful at first but eventually when the time for upgrades arrives, new versions can be further problematic, full of bugs and crashes.
Teams may be moving fast in the beginning but it's possible to slow down greatly. A change here, three breaks in code there. Any change requires a proper understanding of all the tangles, twists and knots to avoid slowing down.
It is important to inform our managers and marketers with the necessary information on which they'll be building their commitments and promises. They may pressure us about the time and schedule but it is our responsibility to make sure we don't rush and compromise good efficient code.
Don't repeat the messy codes you already had problems with just for the sake of meeting deadlines.
One may recognize a problem with a module but it takes 'code-sense' to fix the module. The code sense must be acquired to be a better programmer.
Various programmers have expressed what clean code means to them. All in all, they talk about the code to carry straightforward logic, to the point and made of just useful lines. It makes it elegant and efficient.
We are authors and we are going to have readers. We are constantly old code to write new code or someone would be reading our code to write their code.
The Boy Scout rule, leave the campground cleaner than you found it. Making projects better as time passes by simply rechecking your code from time to time, analyzing it and making minute better changes. Breaking up a function that is too large or removing duplication.
For me, this sums up the first chapter of the book. If I wanna sum this sum up, clear understanding, code sense and responsibility are what this is about. We must clearly understand our role, our responsibilities as developers, and our sense to solve the problems and with this, I would like to share something from the other book, 'The Clean Coder'.
Chapter 1: Professionalism
We often think that being professional in our world means better skills in developing, a better understanding of technology, a better understanding of hardware and assembly, and knowing loads of languages, frameworks and tools. 'That guy is such a pro when it comes to Node.js' or 'Aqsa knows so much about the under-the-hood working of Python, she's such a pro pythonist'. I wouldn't say so much but yeah I do understand some of the working. Anyways, does this guarantee that I'm a professional because I know a few technicalities and have done some work with them?
No, I'm not a pro, at least not right now. Here are some points from the chapter:
Professionalism is about taking responsibility and accountability for the contributions made. These contributions could be good or bad and a professional takes responsibility and accountability for both.
Neglecting or skipping steps is a type of irresponsible behavior, it could lead to problems in the company you worked for. It will also ruin what you have worked so hard on.
Be certain about your code, and do not take testing lightly, it is your responsibility. Make 100% coverage on testing, whether it is unit testing, routine testing or even something innovative you can think of for the sake of your software.
There will be always errors because software can be seriously complex but that doesn't leave you off the hook. It is your responsibility to develop bug-free software.
Do not rely on QA or Quality Assurance to catch bugs and report back to you. This could be expensive for the company and software. A professional program should check things thoroughly and when it reaches QA, there should be no problems.
Automated tests can be beneficial, maybe not for critical missions, but they can at least help to tell you that the system has a high chance of passing the QA.
Your career is in your hands and not in your employer's. They may provide us with training and resources but this is their favor and it is our responsibility to enhance ourselves so we can work for our employer's problem.
Now it doesn't mean our knowledge doesn't add to professionalism. It does if we have knowledge and can make implementations as well as we are skilled in our chosen field. It does account for our professionalism. This is a continuous process though, we must be improving, enhancing and evolving with it.
Skills should be kept sharp and ready. True professionals are those who practice and keep honing themselves in those practice sessions.
In the process of learning, collaboration and mentoring are awesome supporters and catalysts. You may have heard about 'The Feynman Technique', a technique I use a lot while learning and studying.
Understand the domain from all aspects in which you are providing solutions through programming.
A professional is bold and confident but he's never over-confident. There will be times of failure and a professional knows, even full of pride, they'll laugh when they fail.
Isn't this all inspiring? I know not everything here can be inspiring to all, there will be points we may disagree on, but that's okay. Honestly, I even appreciate it, because this means we have got a variety of perspectives and experiences. This is the way to learn, to study, to analyze, to decide, to act upon and then repeat the cycle.
That's it for today, I'll be back to share further on this topic and the coming blogs shall get more specific especially from Clean Code. Till then, Happy clean coding!