Download - Code reviews
Every Programmer Should Know Code Reviews
Roger XiaJuly 2012
$ whoami
• Programmer
Programming & Code review
• Programming is– Taking an algorithm– Choosing a language– Using that language to implement algorithm and
solve problems
• Code review is– ?
Why?
• Increase Quality & Reduce Defects• Improve readability• Share knowledge in team• Know your workmate better!• Two Wrongs Can Make a Right
• NOT personal attack!• NOT architect reviews everything
methodology
• Team review (Planned 1-2 hour/week, Clear roles)
• Pair programming (Share knowledge, 1 task)• Walkthrough (Author leads, reviewers take
notes, higher level)• Peer review (Asynchronous)
• Gerrit• Reaction & Ask questions
Preparation
• Code Conventions• Findbugs• Tested• Test case
Take care of
• naming conventionspelling mistakes
• business logic • refactoring• performance• security (attack, thread safe)
Refactoring• Refactoring modifies software to improve its readability,
maintainability, and extensibility without changing what it actually does.
• Martin Fowler uses “code smells” to identify when to refactor.
• Boss: "Refactoring is an overhead activity - I'm paid to write new, revenue generating features."
Code smells
• Bad names• Duplicate code• Long method• Large class• Long parameter list• Temporary field• Speculative Generality• Data Class• Don’t flood log
Use Meaningful Names
Meaningful Names• Class names
– Should be nouns or noun phrases.– Examples: Car, Account, DataRetrievalService, AddressParser
• Method names– Should be verb or verbPhrases– Examples: parseData, deletePage, save– Methods that return boolean values should sound like question. – Examples: isAuthenticated, hasNoErrors, isEmpty
• Interface and Implementation– ICache LRUCache– IExport ExportService
• Constants– MAX_VALUE– SEP_COMMA, SEP_SEMICOLON
The Art of Readable code
• The book!
• I want to point out:– Use blank to separate logic block.
Comments for complex process, algorithm, reasons
Aiming for simplicity• Do one thing in a function (simple responsibility)• Have no side effects.
• Prefer exceptions to return codes.
• Format your code.
DRY -- Don’t repeat yourself
• Duplicated code should be avoided.• Object Orientation, Abstract!• Design pattern!
OO Principles
• Simple responsibility principle: Class should have one and only one reason to change.
• Encapsulation: Modules should not know internal details of objects it manipulates.
• Polymorphism -- Liskov’s substitution principle: A subclass can be used as an argument where a base class is expected.
• Open-closed principle: Class should be open for extention, but closed for modification.
Design Patterns
Pay Attention to Performance• JAVA: JVM usage
– Don’t create object in loop
– Use ArrayList, HashMap etc as opposed to Vector, Hashtable etc (synchronized) where possible. Even better is to use just arrays where possible.
– Set initial capacity of a collection (e.g. ArrayList, HashMap) and StringBuffer/StringBuilder appropriately.
– Concurrent Collection, Lock
– Lazy load or multi-threading where applicable.
– Cache (LRUCache, Distributed Cache)
Pay Attention to Performance
Pay Attention to Security• Sandbox (security manager, access manager, Classloaders, policies)
• Scope: Access modifier to help protect your classes, methods, fields.– public, protected, private, package– Exceptions: object serialization, reflection,
• Immutable class– final– String– Insecure direct object reference of mutable object
• Type safe– Casting
• Thread safe
• OOM (static), file description handler, release resources (File, DBConnection)
• SQL injection
• Single point of failure
• secure code
Have Fun and winhttp://rosettacode.org/wiki/Rosetta_Code