quality - learning, measurement & awareness
DESCRIPTION
This presentation is all about software quality and it is specially prepared for the event named "Quality Conscious Day, 2011" organized by Vizrt Bangladesh Ltd. In this presentation, we will learn about quality, we will learn how to measure code quality and finally, we will try to grow our awareness on good quality code.TRANSCRIPT
Q U A L I T YLearning - Measurement - Awareness
Super Heroes…
CodeMan
• There is also a super hero inside you!
• Being as a…
Code Man
• Because you can CODE!!!
Note: the idea of CodeMan is borrowed from one of my ex-colleagues, Hasan
CodeMan has Super Responsibility
But…
Super natural power comes with
Super responsibility!
Power without control hardly has any value.
Because…
Responsibilities of a CodeMan
Learn how to control power
Measure the quality of work
Awareness for quality work
What is QUALITY ?
Oxford American Dictionary says -
the standard of something as measured against other things of a
similar kind.
It is NOT easy to define Quality.
“You may not know how to define it, but you know it when you see it.”
- Erik Doernenburg, Head of Technology, ThoughtWorks Europe
CodeMan – Story 1
- Manager asks CodeMan to upload his profile picture in Wiki.
- The CodeMan quickly uploads one of his photos.
- Now, imagine the immediate reaction of the manager!!!
CodeMan – Story 2
The CodeMan wrote a method and committed it to VCS as soon as he tested it successfully:
Few months later, a critical bug is found in this code.
While going through the code, the second CodeMan hardly gets any idea what this piece of code block is doing.
And the immediate reaction that pops up in his mind: WTF !!!
Measuring Code Quality – WTFs / minute
Measuring Code Quality
It is very important to measure the QUALITY of your CODE.
If you don’t know whether your code quality is GOOD or BAD, then you can never improve your code.
Why Quality Code ?
Single purpose
Changeability – keeping your code changeable
3 key factors
Readability: only easily readable code can easily be understood and therefore changed
“Programs MUST be written for people to read, and only incidentally for machines to execute.” - Abelson and Sussman
Simplicity: simple is always easier to change than complicated
Testability: only automatically tested code can be changed without fear of breaking existing behavior.
How to Improve CODE Quality?
How can we improve our CODEQUALITY?
How can we minimize the number of WTFs
in our CODE?
How to Improve CODE Quality?
1. Code conventions
2. KISS - keeping it stupid simple
3. No RUSH
4. Code reviews
5. Pair programming
6. Automatic build and deployment
7. Incorporating QA process
8. Improve your own quality
Code Conventions
Every programming language has some set of guidelines.
Things you should strictly follow:- Naming conventions
- Coding style guidelines- Exception handling guidelines- Unit testing principles- Principles of object oriented design
Configure your IDE, use necessary plugins. These tools eliminate the need for reviews focusing on coding style and basic design. They allow us to put our energy into higher concepts of quality.
KISS - Keep it Stupid Simple
Don’t build Rube Goldberg Machines – something complex to do simple things
KISS - Keep it Stupid Simple
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies
- Sir Charles Antony Richard Hoare AKA Tony Hoare
KISS principles:
1. Split your task into smaller subtasks
2. Break down a complex problem into many smaller and simple problems
3. Keep your methods small, should not more than 30~40 lines
4. Keep your classes small – same methodology as for methods. Follow OOP principles.
5. Solve the problem first, then code it.
Don’t be too clever , No RUSH
Clear, not Clever Be Clear, not too Clever
Don’t code in a Hurry — ”Haste is Waste”
Take your time to read the code and see if it is what you meant
Take your time to write tests — make sure the code does what you meant, not what you typed
Code defensively
Act in haste and repent at leisure… Code too soon and debug forever…
Code Reviews
Periodic inspection of selected parts of the code.
Normally, only critical code should be reviewed extensively
Compare the code at hand with the clean code guidelines and other quality goals.
Everyone writes bad code from time to time, but having code reviews eliminates a lot of it.
Always try to be nice to your colleagues, and never think that you know better. Be humble since it's actually easy to be wrong about stuff. :-)
Constructively propose changes. Say positive things, what you really like. Instead of “that’s lousy long method” say, “why don’t you split that method...”
Code reviews doesn't only eliminate poor code written by team members (and yourself), but is a great way to learn new things from each other.
Tools: Crucible, Sonar etc.
Code Reviews - Crucible
Code Reviews - Sonar
Pair Programming
Pair programming is a key practice to quality.
Advantages:
1. The code is already reviewed by a second developer.
2. The code is built with the combined technical excellence of two developers. This includes the advantages that it is more likely that alternatives are discussed and a better solution results than in the case of a single developer working on the task.
3. Know-how is transferred between the pairing developers. Know-how about the problem domain, technical excellence and even tool usage is shared
Continuous Build and Deployment
Early build and deploy => Early discover bugs => Early Fix
Whenever a developer commits/checks-in code into the VCS, the continuous integration server starts checking the code.
A typical scenario consists of
1. building the source code,
2. running all automated unit and acceptance tests,
3. checking coding guidelines automatically as far as possible
4. creating an installer package
5. finally deploying the installer package of the application on a test system for additional manual testing.
Incorporating the QA process
Traditional software development process:
1) finish most of the developments first
2) then QA engineers start testing
But this doesn’t work:
1) QA engineers doesn’t get enough time
2) software is released with lots of untested functionality
What actually works:
1) Incorporate QA process with development
2) QA process starts as soon as a very small functionality implemented.
Improve your own Quality
Improve yourself first.
Minimize the number of bugs.
well, this a not a critical bug.
I can fix it within few minutes.
Ask 3 questions before fixing your bug:
1. Have I made this error anywhere else?
2. What happens when I fix the bug?
3. How can I change my ways to make this kind of bug impossible?
3 Simple Tips
QUALITY should be possessed in your MIND,
not only in your CODE.
QUALITY has to be possessed in your MIND,
not only in your CODE.
QUALITY must be possessed in your MIND, not only in your CODE.
T H A N K Y O U
Ferdous Mahmud ShaonSenior Consultant, Professional Services, VizrtEmail: [email protected]: @fmshaon