Code reviews

495 views

Published on

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
495
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • Loose couple:FacadeSpringMessaging
  • Temporary fieldAn attribute of an object is only set in certain circumstances; but an object should need all of its attributes Speculative Generality“Oh I think we need the ability to do this kind of thing someday” Data ClassThese are classes that have fields, getting and setting methods for the fields, and nothing else; they are data holders, but objects should be about data AND behavior
  • http://www.slideshare.net/srikanthps/practices-for-becoming-a-better-programmer-presentation
  • Are we writing comments because our code is unclear?Will you keep the comments up-to-date whenever code is updated?
  • If there is a bug in the code or code requires changes, then, one has to change it at multiple places.
  • http://www.lifeyun.com/design-pattern-diagram.html
  • http://www.artima.com/insidejvm/ed2/jvm2.html
  • http://www.artima.com/insidejvm/ed2/jvm2.html
  • Mitigation of serialization:- Don’t extend java.io.serializable- ImplementreadObject and writeObject as final methods that throw IOException- If serialize you must: use transient or use java.io.Externalizeable plus Encryption
  • Code reviews

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

    ×