Software Craftsmanship - Introduction to Code Smells
•
0 likes•57 views
This is my second presentation on software craftsmanship. My previous presentation was a high level view highlighting the dire need of software craftsmanship on top of agile in software development. This presentation (and the subsequent series on code smells) deep dives into the technical aspect of software craftsmanship highlighting ways to structure your code and write a well crafted software.
Recommended
More Related Content
What's hot
What's hot (19)
More from Rajat Singla
More from Rajat Singla (8)
Recently uploaded
Recently uploaded (20)
Software Craftsmanship - Introduction to Code Smells
- 2. Code Review Code Review WTF! Hmm.. WTF is this sh**! WTF! We are in deep trouble! WTF! Dude, WTF! When is this going to end! Good Code Bad Code
- 4. Cost of Software Readability. Why? Understand Analyze Create/Change Test Build Deploy
Editor's Notes
- This is my second presentation on software craftsmanship. My previous presentation was a high level view highlighting the dire need of software craftsmanship on top of agile in software development. This presentation (and the subsequent series on code smells) deep dives into the technical aspect of software craftsmanship highlighting ways to structure your code and write a well crafted software.
- What according to you is a good code? Or what according to you is a bad code? How do we measure code quality? There is a very simple method to determine whether a code is good or bad. Imagine yourself having a code review with your team. The count of WTFs shouted per minute in the room is all you need to determine whether your code is good or not!
- The ideal requirements for a code to be labeled Good are: It should be Readable. People should not have a confused expression on their faces while reading your code. The code should clearly depict the intentions of the programmer. Every line that goes inside your code should be a depiction of the business scenario it is representing. Just by looking at the code, a person should be able to deduce what the code is doing and how it is done. It should be Extensible. Requirements keep on changing. Every day new features come up. The code should have an ability to accommodate the ever increasing demand of features without exploding. If you find it really hard to accommodate a small feature in your code, it is a sign of imminent explosion and your code should be restructured immediately. It should be Maintainable. A code which does not stand the test of time, is a code with zero value. Your code should not only aim to solve the immediate problem at hand, but should be robust enough to handle problems in the future. Most often than not, person maintaining the code is different from the person who has developed it. If it takes hours to understand your code it is not maintainable. If for a small change in requirement, you are forced to change huge amount of code, your code is at a risk of breaking down and it is definitely not maintainable (your code might have high coupling). Would you buy a car which demands high cost of maintenance and requires you to visit dealership often?
- Often when I tell people that readability is the most important aspect of your code, people quickly disregard it thinking I am a guy obsessed with beautifying my code and keeping things organized. What they fail to understand is that beautiful code is not really a reason, but a result of taking care of perhaps the most important factor determining the cost of your software! What factors determine the cost of your software? Lets start by writing down the steps involved in creating one! Analyze -> Change/Create -> Test -> Build -> Deploy. It is fairly understandable that time spent on each stage is in the decreasing order. We all know, the cost involved is a direct function of time, specially when it comes to software development (Time = Money, Duh!). So the cost goes in the decreasing order as well. FAIR ENOUGH! Are we not missing something? What most people fail to consider in their time analysis of creating a software is the time it takes to Understand the Problem! Ask yourself, how much time you spend understanding a piece of code before working on it. Where do you think, the stage of understanding fits in this chain? RIGHT AT THE TOP! Isn’t it? Doesn’t it mean that the cost of understanding is higher than all other costs? Wouldn’t reducing time involved in this stage reduce the cost of your software immensely? And what is the single most important factor determining the time involved in understanding the code? It is CODE READABILITY!! Making your code readable should thus be of prime importance while writing you code. A beautiful code is just a side effect of this task. And lets not call it beautiful. Technically, it should be called a “well structured code”. And the tool that is available to every developer for doing this, is FREE OF COST! It is called REFACTORING! Common argument: What about performance? Answer: MAKE YOUR CODE READABLE FIRST! THEN LOOK FOR PERFORMANCE! -> MAKE IT WORK, THEN MAKE IT BETTER! (how to make it readable - e.g. Guard Clause, Intention Revealing Names etc.)
- Now how do we know that code we have written is good or bad? Is it a subjective opinion or is there any metrics to determine whether it is readable/extensible/maintainable? Luckily for us, there IS A METRIC! When you go past a garbage can, you tend to block your nose, as the foul smell is almost unbearable. When there is something wrong with the code, we say there are certain elements in it which stink, making the whole code stink as well! These stinky elements are referred to as code smells. Now, when it comes to real life objects, the sense of foul smell is an innate human tendency. But when it comes to code, we need to teach ourselves to identify these code smells. In other words, we need to develop a nose to identify foul smells in the code. And this ability can only be developed when you are relatively young (new to development). As soon as a hatchling starts flying, its mother teaches it to hunt, for it won’t survive in its adulthood without the ability. The same goes with the ability to smell stink inside the code. It becomes harder and harder to develop this ability as we grow further into software development without it. For it is easier to learn than to unlearn. Writing a code with wrong practices is more dangerous than not writing the code at all! IT IS VERY IMPORTANT FOR ANY YOUNG DEVELOPER TO DEVELOP A NOSE FOR THESE CODE SMELLS! There are broadly 5 categories these code smells are divided into. The subsequent slides will talk about each of them in detail, highlighting different ways these code smells make your code stink and how to identify these smells and remove them.