Code reviews

Code reviews

• 1.
  Every Programmer ShouldKnow Code Reviews Roger Xia July 2012
• 2.
  $ whoami • Programmer
• 3.
  Programming & Codereview • Programming is – Taking an algorithm – Choosing a language – Using that language to implement algorithm and solve problems • Code review is –?
• 4.
  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
• 5.
  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
• 7.
  Preparation • Code Conventions • Findbugs • Tested • Test case
• 8.
  Take care of •naming convention spelling mistakes • business logic • refactoring • performance • security (attack, thread safe)
• 9.
  Refactoring • Refactoring modifiessoftware 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."
• 10.
  Code smells • Bad names • Duplicate code • Long method • Large class • Long parameter list • Temporary field • Speculative Generality • Data Class • Don’t flood log
• 11.
  Use Meaningful Names
• 12.
  Meaningful Names • Classnames – 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
• 13.
  The Art ofReadable code • The book! • I want to point out: – Use blank to separate logic block.
• 14.
  Comments for complex process,algorithm, reasons
• 15.
  Aiming for simplicity •Do one thing in a function (simple responsibility) • Have no side effects. • Prefer exceptions to return codes. • Format your code.
• 16.
  DRY -- Don’trepeat yourself • Duplicated code should be avoided. • Object Orientation, Abstract! • Design pattern!
• 17.
  OO Principles • Simpleresponsibility 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.
• 18.
  Design Patterns
• 19.
  Pay Attention toPerformance • 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)
• 20.
  Pay Attention toPerformance
• 21.
  Pay Attention toSecurity • 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
• 22.
  • secure code
• 23.
  Have Fun andwin http://rosettacode.org/wiki/Rosetta_Code