code reviews

23
Every Programmer Should Know Code Reviews Roger Xia July 2012

Post on 23-Sep-2014

567 views

Category:

Technology


3 download

DESCRIPTION

 

TRANSCRIPT

Page 1: Code reviews

Every Programmer Should Know Code Reviews

Roger XiaJuly 2012

Page 2: Code reviews

$ whoami

• Programmer

Page 3: Code reviews

Programming & Code review

• Programming is– Taking an algorithm– Choosing a language– Using that language to implement algorithm and

solve problems

• Code review is– ?

Page 4: Code reviews

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

Page 5: Code reviews

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

Page 6: Code reviews
Page 7: Code reviews

Preparation

• Code Conventions• Findbugs• Tested• Test case

Page 8: Code reviews

Take care of

• naming conventionspelling mistakes

• business logic • refactoring• performance• security (attack, thread safe)

Page 9: Code reviews

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."

Page 10: Code reviews

Code smells

• Bad names• Duplicate code• Long method• Large class• Long parameter list• Temporary field• Speculative Generality• Data Class• Don’t flood log

Page 11: Code reviews

Use Meaningful Names

Page 12: Code reviews

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

Page 13: Code reviews

The Art of Readable code

• The book!

• I want to point out:– Use blank to separate logic block.

Page 14: Code reviews

Comments for complex process, algorithm, reasons

Page 15: Code reviews

Aiming for simplicity• Do one thing in a function (simple responsibility)• Have no side effects.

• Prefer exceptions to return codes.

• Format your code.

Page 16: Code reviews

DRY -- Don’t repeat yourself

• Duplicated code should be avoided.• Object Orientation, Abstract!• Design pattern!

Page 17: Code reviews

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.

Page 18: Code reviews

Design Patterns

Page 19: Code reviews

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)

Page 20: Code reviews

Pay Attention to Performance

Page 21: Code reviews

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

Page 22: Code reviews

• secure code

Page 23: Code reviews

Have Fun and winhttp://rosettacode.org/wiki/Rosetta_Code