Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
Coding: Styles, Reviews, and Metrics
CSC 440/540: Software Engineering Slide #1
Topics
1. Technical Debt
2. Coding Styles
3. Code Reviews
4. Going Further
CSC 440/540: Software Engineering Slide #2
Technical Debt
Technical debt is the extra development work that
arises when code that is easy to implement in the short
run is used instead of writing the best overall solution.
Sources of technical debt
Business pressures.
Lack of process.
Lack of a test suite.
CSC 440/540: Software Engineering Slide #3
Cost of Technical Debt
CSC 440/540: Software Engineering Slide #4
Technical Debt Quadrant
CSC 440/540: Software Engineering Slide #5
Coding Styles
Code is more often read than written.
Optimize for readability.
By all programmers on your team.
Readability is a superset of consistency.
Pick a coding style then use it consistently.
2 vs. 4 vs. 8 character tabs don’t matter; just pick one.
Publish and automate coding styles
Publish a coding style document.
Use tools (gofmt, indent) to automate formatting.
CSC 440/540: Software Engineering Slide #6
Coding Style Guides
Google Guides
https://github.com/google/styleguide
Oracle/Sun Java Style Guide
http://www.oracle.com/technetwork/java/javase/docum
entation/codeconvtoc-136057.html
Python Style Guide (PEP-8)
https://www.python.org/dev/peps/pep-0008/
Community Ruby Style Guide
https://github.com/bbatsov/ruby-style-guide
CSC 440/540: Software Engineering Slide #7
https://github.com/google/styleguidehttp://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html
Naming
Use names that reveal intentions
Use fileAgeInDays instead of just days.
Use searchable names
This is an important reason to name constants too.
Pick one word per concept
Choose one from synonyms like fetch, get, retrieve.
Object-oriented names
Use nouns to name classes.
Use verbs to name methods.
CSC 440/540: Software Engineering Slide #8
Code Reviews
Inspection of source code by one or more people who
aren’t the author of the code.
Goal: Identify defects for later removal.
People: Moderator, reviewers.
Scope: Module or small set of classes.
Time: 1-2 hours;
Benefits of Code Reviews
1. Find defects sooner in the lifecycle.
(IBM finds 82% of defects before testing.)
2. Find defects with less effort than testing.
(IBM—rev: 3.5 hrs/defect, test: 15-25 hrs/defect.)
3. Find different defects than testing.
(Can identify design and requirements problems too.)
4. Educate developers about security bugs.
(Developers frequently make the same mistakes.)
CSC 440/540: Software Engineering Slide #10
Resistance to Code Reviews
Perceived Cost
Takes time to prepare materials and review them.
Adds meetings to schedule.
Programmer Fears
Fear of having other people read their code.
Fear of being blamed for mistakes.
Fear of investing time in other developer’s code.
Fear of missing deadlines due to time spent on reviews.
CSC 440/540: Software Engineering Slide #11
Inspections
Most formal process.
Thorough coverage with separated roles.
Use checklists to focus on specified goals.
Collect metrics to track defects.
Determine whether further inspections of revised
software needed at end of meeting.
Extensive documentation of effectiveness.
One study found 16-20 defects/kloc with inspections
compared with 3 defects/kloc in informal walkthrough.
CSC 440/540: Software Engineering Slide #12
Roles in Reviews
1. Moderator
Manages meeting; follows up on issues.
2. Reader
Paraphrases code during meeting.
Not the author.
3. Recorder
Records bugs discovered.
4. Author
Provides context for code; answers questions.
Makes corrections after code review.
CSC 440/540: Software Engineering Slide #13
Walkthroughs
Less formal process.
Author leads meeting and describes code.
Focus on author needs, not quality goals.
No checklists used or metrics gathered.
Quality varies widely.
Walkthrough quality depends solely on author.
Useful for educating developers about code, provide high
level view of design and defects.
CSC 440/540: Software Engineering Slide #14
Code Review Process
Planning
Author
Moderator
Prep
Everyone
Meeting
Everyone
Rework
Author
Follow-up
Author
Moderator
CSC 440/540: Software Engineering Slide #15
Planning
1. Author initiates Planning once code ready.
2. A Moderator is assigned to inspection.
3. Author and Moderator assemble inspection pkg.
4. Moderator identifies other participants.
Planning
Author
Moderator
Prep
Everyone
Meeting
Everyone
Rework
Author
Follow-up
Author
Moderator
CSC 440/540: Software Engineering Slide #16
Preparation
1. Reviewers examine inspection package.
2. Reviewers use checklists and analysis tools.
3. Reviewers mark bugs found.
Planning
Author
Moderator
Prep
Everyone
Meeting
Everyone
Rework
Author
Follow-up
Author
Moderator
CSC 440/540: Software Engineering Slide #17
Meeting
1. Reader describes code in own words.
2. Reviewers comment and ask questions.
3. Recorder notes all potential bugs, suggestions.
4. Team appraises code at meeting conclusion.
Planning
Author
Moderator
Prep
Everyone
Meeting
Everyone
Rework
Author
Follow-up
Author
Moderator
CSC 440/540: Software Engineering Slide #18
Rework
Author addresses issues recorded at meeting.
Planning
Author
Moderator
Prep
Everyone
Meeting
Everyone
Rework
Author
Follow-up
Author
Moderator
CSC 440/540: Software Engineering Slide #19
Follow-up
1. Moderator meets with Author about rework.
2. Moderator verifies all changes made correctly.
3. Author checks in corrected code.
Planning
Author
Moderator
Prep
Everyone
Meeting
Everyone
Rework
Author
Follow-up
Author
Moderator
CSC 440/540: Software Engineering Slide #20
Code Review Tips
1. Do small and frequent code reviews.
Typical review speed is 150-200 lines/hour
2. Know what bugs to look for.
Checklists
Static analysis tools
3. Use tools.
Simple tools: grep, findstr
Code viewers
Static analysis tools
4. Require preparation before the meeting.
CSC 440/540: Software Engineering Slide #21
ChecklistsCode reviews should include checklists ofcommon problems, including:
1. SQL injection
2. Cross-site scripting
3. Input validation bugs
4. Checking return values
5. Resource name canonicalization
6. Race conditions
CSC 440/540: Software Engineering Slide #22
Code Review Problems
1. Requires substantial expertise in area of
programming and security to be effective.
2. Human readers are fallible and will miss mistakes.
3. Code reviews take time. Unreviewed legacy code can
take an enormous amount of time to handle, so you
need a way to prioritize which code to review.
CSC 440/540: Software Engineering Slide #23
Prioritizing Code
If you can’t review everything, review
Code that runs with privileged mode.
Code that listens on globally accessible sockets.
Code that is accessible w/o authentication.
Code with a history of vulnerabilities.
Code that handles sensitive data.
Complex code.
Code that changes frequently.
CSC 440/540: Software Engineering Slide #24
Reviewing for SQL Injection
CSC 440/540: Software Engineering Slide #25
Ex: Zune infinite loop on 12/31/08
year = 1980;
while (days > 365) {if (IsLeapYear(year)) {
if (days > 366) {days -= 366;year += 1;
}} else {
days -= 365;year += 1;
}}
CSC 440/540: Software Engineering Slide #26
Going Further
CSC 440/540: Software Engineering Slide #27
References
1. Martin Fowler, “Technical Debt Quadrant,” http://martinfowler.com/bliki/TechnicalDebtQuadrant.html, 2009.
2. Michael Howard, “A Process for Performing Security Code Reviews.” IEEE Security & Privacy, July 2006.
3. Eoin Keary et. al., OWASP Code Review Guide 1.1, http://www.owasp.org/index.php/Category:OWASP_Code_Review_Project, 2008.
4. Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship, Prentice Hall, 2008.
5. Steve McConnell, Code Complete, 2/e, Microsoft Press, 2004.
6. Karl Wiegers, Peer Reviews in Software, Addison-Wesley, 2002.
CSC 440/540: Software Engineering Slide #28
http://martinfowler.com/bliki/TechnicalDebtQuadrant.htmlhttp://www.owasp.org/index.php/Category:OWASP_Code_Review_Project