12. “
Code review is systematic
examination (sometimes referred to
as peer review) of computer source
code. It is intended to
find mistakes overlooked in
the initial development phase,
improving the overall quality of
software.
- Wikipedia
12
13. Not only for software
development
○ Architects – Red Line Reviews
○ Engineers – Peer Reviews
○ Doctors – Consultations
○ Welders – Welding Review
13
14. “
Code review is systematic
examination (sometimes referred to
as peer review) of computer source
code. It is intended to
find mistakes overlooked in
the initial development phase,
improving the overall quality of
software.
- Wikipedia
14
15. Why the focus on
finding bugs sooner?
Bugs cost more
the later they’re found
15
16. How Many Times
More?
16
Time
Introduced
Requirements Architecture Construction System
Test
Post
Release
Requirements 1 3 5-10 10 10-100
Architecture - 1 10 15 25-100
Construction - - 1 10 10-25
from Code Complete 2nd Edition
17. How Much
Savings?
IBM found that each hour of
inspection prevented about 100 hours
of related work
Assuming $25 an hour, that means
for every $25 invested, $2500 was
saved.
17
18. How Much
Savings?
Raytheon reduced its cost of rework
from 40% of project cost to 20% of
project cost
The amount spent on bug fixes
dropped by 50%
18
36. 36
When returning records from the database and
there aren’t any, we should return an empty list
because all of the list methods work on an empty
list and we don’t have to introduce error handling
code
37. 37
When returning records from the database and
there aren’t any, we should return an empty list
because all of the list methods work on an empty
list and we don’t have to introduce error handling
code
38. 38
When returning records from the database and
there aren’t any, we should return an empty list
because all of the list methods work on an empty
list and we don’t have to introduce error handling
code
39. 39
When returning records from the database and
there aren’t any, we should return an empty list
because all of the list methods work on an empty
list and we don’t have to introduce error handling
code
41. “
What should you do when
the array is empty?
41
Reinforce Joint Ownership
42. “
What should you do when
the array is empty?
What should we do when
the array is empty?
42
Reinforce Joint Ownership
43. “
This for loop is garbage,
what in the world were
you thinking?!
43
Code Is The Problem
44. “
This for loop is garbage,
what in the world were you
thinking?!
I’m having issues
understanding this for
loop, can you step me
through what it’s doing?
44
Code Is The Problem
50. Quality
○ Are inputs handled correctly?
○ Is the right answer computed?
○ How about nulls? Empty Arrays?
Negative numbers, etc?
○ What about edge cases?
○ Are errors handled gracefully?
○ Does the app crash?
○ Is the user presented with a
message?
50
52. Readability
○ Determined by your team
○ Clear beats clever, but what makes
code “clear”?
○ Write code simple enough for your
team to understand, but strive to
improve the lower bound
52
53. Maintainability
○ Code is in flux
○ The longer it takes to make changes…
○ The more expensive the work
○ More likely to make mistakes
○ Are certain design principles being
followed?
○ SOLID, DRY, YAGNI, KISS 53
54. Style
○ Does this C# code look like it was
written by a C# developer? Or more like
a Ruby developer?
○ Focus on
○ Naming conventions
○ Proper coding constructs
○ Project structure
54
56. Next Steps
Ask someone you respect to review your
work
○ Company == Coworker
○ Side Project == Friend
56
57. Next Steps
Implement Code Review Process at work?
○ Convincing your boss? Code Complete
by Steve McConnell
○ Trying to design the process?
Brainstorming About Code Reviews by
Geoff Mazeroff
57
58. 58
Resources
○ The Clean Coder: A Code of Conduct for Professional Programmers by
Robert C. Martin
○ 11 Proven Practices For More Effective, Efficient Peer Code Review
○ Code Complete 2nd Edition by Steve McConnell
○ Brainstorming About Code Reviews by Geoff Mazeroff
○ http://blog.TheSoftwareMentor.com/presentations/#CodeReviews
What about this?
What about that?
Question after question after question
Critiqu after critique
Multiple hour beating
Feel exhausted
So many changes
Did you really accomplish anything?
Code Reviews Take Too Long…
Plenty of incentives for companies to have code reviews
Responsible for doing what’s best for our employer
But what about us?
Developers start out knowing how to write code, but not much finesse
Takes time to learn the nuances of development
Not just time on the job, it’s constantly learning new techniques and perspectives
5 years of experience, but each year introduces something new
The same year 5 times?
Learn from those who came before you
Always someone who knows more than you and code reviews can help share that knowledge
Makes your more employable (i.e. easier to get a job)
Makes you more valuable (i.e. get paid more and less likely to be let go)
Reviewing too much
Can’t review ton of changes and expect to find issues
How much code is too much?
IBM partnered with SmartBear and Cisco to determine some best practices for code reviews
Published as 11 Best Practices for Code Review
The study involved 2,500 code reviews, 50 programmers and 3.2 million lines of code at Cisco Systems
Defect density – review effectiveness, looking for high points on the Y axis
Once we hit 200 LOC, we start dropping in effectiveness
Once we hit 400 LOC, effectiveness goes to 0
Strive for smaller pieces of work
Big changes will happen, need to have more frequent code reviews
Opinion Based Improvements
“If we’re retrieving an array of records from the database, we should return an empty array if the database is empty instead of returning a null because the return choices for an array should either be empty or a collection of those records”
Never, really, there is no instance when this would make sense?
Only a Sith deals with absolutes….
When is the keyword (i.e. when should we do this)
What: what do we do in this situation
Why should we do this?
Lead into attacking the developer section
It’s normal for developers to be anxious for another to review their work
Especially when starting out, we can’t just call each other crap
Notice how we’re placing blame or onus on the developer?
By switching out you for we, it’s more collaborative
Tone implies that the code is bad
Is it because of quality or is it because I don’t understand
(Two different problems!!!)
Puts the problem on me and allows the developer to step through their code
I may be learning a new trick here.
Lecturing
Typically find this with a senior working with a junior
One person doing all the talking
Tight Collaboration
Everyone is talking and engaged
Not a lecture
Knowledge Sharing
One developer should not be solely responsible for a part of the application.
Leads to problems like we can’t make changes without Cameron here
By sharing business knowledge and the design of the code, other developers can pick up the context quickly
Bus Factor
How many people could be hit by a bus before the project suffered?
Concise for one team is unintelligible for another
No surprises, the team can understand it
Don’t mention tools because they’re an afterthought
Tools automate the process
Tools don’t dictate the process, the process dictates the tools
If application is service oriented, then it shouldn’t be following a layered approach
It’s okay to have technical debt, but mortgage on home, not Ferrari on credit card
You’re writing tests, right…?
View Report option is under the “About” menu
Dumping an exception to the main window
Telling the user the application lost connection to its database
If we can’t consistently reproduce the problem, how will we know when it’s fixed?
Have we found the source of the problem, or are we patching a symptom?
If we have a problem here, we can scrap the review and address the issue
You’ll have a feeling that there was a cleaner way to solve an issue, but you don’t know how to fix it. Perfect opportunity to get a second set of eyes