Code Review


Published on

Published in: Education, Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Code Review

  1. 1. Code Review
  2. 2. What is it ? <ul><li>code review is a special kind of inspection in which the team/member examines a sample of code and fixes any defects in it. In a code review, a defect is a block of code which does not properly implement its requirements, which does not function as the programmer intended, or which is not incorrect but could be improved. </li></ul>
  3. 3. And why ? <ul><li>It's one of the best ways to ensure good code quality and provides an excellent way to share domain knowledge with team members who may otherwise not get the opportunity.It also allows experienced developers to share their knowledge and ideas with less experienced developers, an excellent way of distributing development skills across an entire team. </li></ul>
  4. 4. And why ? <ul><li>Code quality increases as the number of support calls decreased and the number of reported bugs decreased as well.The benefits of code review can be a more stable product, more maintainable code as it applies to structure and coding standards, and it allows developers to focus more on new features rather than “fire-fighting” bugs, and other production issues. </li></ul>
  5. 5. And Why ? <ul><li>Finds and fixes maintain ability issues such as documentation, organization, architecture, usability, efficiency, robustness, maintainability, and portability. All of these things affect overall code quality </li></ul><ul><li>Makes engineers more familiar with parts of the code base they might never see otherwise, breaking down the “my code/your code” silos and giving your engineering team much broader exposure to the entire codebase. </li></ul>
  6. 6. Issues ... <ul><li>Never Following Through :The author simply takes no notice of the comments or suggests </li></ul>
  7. 7. Issues ... <ul><li>Lack of Buy In :This is one of the hardest hurdles to overcome.When a team simply doesn’t buy-in to the idea of code reviews, it will be difficult to get anything useful out of a review </li></ul>
  8. 8. Issues ... <ul><li>Talking Unrealistic Expectations : </li></ul><ul><li>If ( (int)$x > (int)$y) </li></ul><ul><li>{ </li></ul><ul><li>// do something </li></ul><ul><li>} </li></ul><ul><li>If $x=2323223232323232325656 and $y=5 </li></ul><ul><li>The maximum value depends on the system. 32 bit systems have a maximum signed integer range of -2147483648 to 2147483647. So for example on such a system, intval('1000000000000') will return 2147483647. The maximum signed integer value for 64 bit systems is 9223372036854775807 </li></ul>
  9. 9. Issues ... <ul><li>Peer Fear : :-) so many reasones ... </li></ul>Big Brother is now watching and grading me on my defects! Code review takes time we don’t have, and we’ll miss our deadline! etc ...
  10. 10. Solutions? <ul><li>It’s not always easy .... </li></ul>
  11. 11. Code Review Types <ul><li>Over-the-shoulder : One developer looks over the author's shoulder as the latter walks through the code. </li></ul><ul><li>Email pass-around : The author emails code to reviewers. </li></ul><ul><li>Pair Programming : Two authors develop code together at the same workstation. </li></ul><ul><li>Tool-assisted : Authors and reviewers use specialized tools designed for peer code review. </li></ul>
  12. 12. Peer Review <ul><li>An activity in which people other than the author of a software deliverable examine it for defects and improvement opportunities.Peer review methods include inspections, walkthroughs, peer deskchecks, and other similar activities. </li></ul>
  13. 13. Peer Review... If you don't understand a function or method in 30 seconds, it is probably too complex It's easy to code for computers, but hard to code for humans
  14. 14. Peer reviews can take many forms <ul><li>An inspection : is the most systematic and rigorous type of peer review. Inspection follows a well-defined multistage process with specific roles assigned to individual participants. Inspections are more effective at finding defects than are informal reviews. </li></ul><ul><li>Team reviews : are a type of “inspection-lite,” being planned and structured but less formal and less rigorous than inspections. Typically, the overview and follow-up inspection stages are simplified or omitted, and some participant roles may be combined (e.g., moderator and reader). </li></ul>
  15. 15. Peer reviews can take many forms <ul><li>A walkthrough : is an informal review in which the work product’s author describes it </li></ul><ul><li>to some colleagues and solicits comments. Walkthroughs differ significantly from </li></ul><ul><li>inspections because the author takes the dominant role; other specific review roles are </li></ul><ul><li>usually not defined. Walkthroughs are informal because they typically do not follow a </li></ul><ul><li>defined procedure, do not specify exit criteria, require no management reporting, and </li></ul><ul><li>generate no metrics. </li></ul><ul><li>In pair programming : two developers work on the same program simultaneously at a </li></ul><ul><li>single workstation, continuously reviewing their joint work. Pair programming lacks </li></ul><ul><li>the outside perspective of someone who is not personally attached to the code that a </li></ul><ul><li>formal review brings. </li></ul>
  16. 16. Peer reviews can take many forms <ul><li>In a peer deskcheck: only one person besides the author examines the work product. </li></ul><ul><li>A peer deskcheck typically is an informal review, although the reviewer could </li></ul><ul><li>employ defect checklists and specific analysis methods to increase effectiveness. </li></ul><ul><li>A passaround : is a multiple, concurrent peer deskcheck, in which several people are </li></ul><ul><li>invited to provide comments. The passaround mitigates two major risks of a peer </li></ul><ul><li>deskcheck: the reviewer failing to provide timely feedback and the reviewer doing a </li></ul><ul><li>poor job. </li></ul>
  17. 17. Better code .. code/review - 1 <ul><li>All of the participants in a review should avoid personally attacking the person being reviewed with statements such as “why did you do it that way?” or “what were you thinking?” etc. These types of comments diminish the trust between peers, leading to animosity, hours of arguing over the best/right way to code a solution. Keep in mind that developers do not think or code exactly the same, and there are many solutions to a problem. Just a little clarification on over-the-shoulder reviews; these can be conducted via remote desktop sharing (pick flavor here), or in person. However, they shouldn’t be limited to the developers only. </li></ul>
  18. 18. Better code .. code/review - 2 <ul><li>Consistently Format Source Code </li></ul><ul><li>Format source code consistently </li></ul><ul><li>Establish a coding standard </li></ul><ul><li>How to indent </li></ul><ul><li>Where to put whitespace </li></ul><ul><li>Capitalization </li></ul><ul><li>Reuse existing coding standards </li></ul>
  19. 19. Better code .. code/review - 3 <ul><li>Create API Documentation (Use Trac wiki or any other centrlized place where each developer can easily go and understand documentation about module or code) </li></ul><ul><li>Use PHPdoc (if you have put proper inline commenting in code) </li></ul><ul><li>Special @tags </li></ul><ul><li>(@author, @version, @param,@returns, …etc) </li></ul>
  20. 20. Better code .. code/review - 4 <ul><li>Eliminate Redundant Code </li></ul><ul><li>Avoid duplicate or similar code </li></ul><ul><li>The Goal is: Make code changes in </li></ul><ul><li>just one spot </li></ul><ul><li>Create parametrized functions and </li></ul><ul><li>methods (“helper functions”) </li></ul><ul><li>Do not over-generalize when </li></ul><ul><li>programming, use Refactoring </li></ul>
  21. 21. Better code .. code/review - 5 <ul><li>Shorten Code Blocks </li></ul><ul><li>Break down code into little pieces </li></ul><ul><li>A method or function should fit on </li></ul><ul><li>the screen without scrolling </li></ul><ul><li>When the code needs (too many) </li></ul><ul><li>inline comments, it may be too </li></ul><ul><li>complex </li></ul><ul><li>No more than three nesting levels </li></ul>
  22. 22. Better code .. code/review - 6 <ul><li>Replace Implementations ... </li></ul><ul><li>Use native PHP instead of an old extension </li></ul><ul><li>Use components (PEAR,SPL,ezComponents etc.) </li></ul><ul><li>Use PHP extensions(XMLWriter, SOAP) </li></ul>
  23. 23. Better code .. code/review - 7 <ul><li>Refactoring </li></ul><ul><li>Changing code to improve readability </li></ul><ul><li>Changing code to simplify the structure </li></ul><ul><li>Without changing the results </li></ul><ul><li>Not adding new functionality </li></ul><ul><li>'Clean Up' the code </li></ul><ul><li>Improve the design </li></ul>
  24. 24. Better code .. code/review - 8 <ul><li>Why Refactor ? </li></ul><ul><li>The world constantly changes </li></ul><ul><ul><li>environment changes </li></ul></ul><ul><ul><li>terminology changes </li></ul></ul><ul><ul><li>requirements change </li></ul></ul><ul><li>Software design decays over time </li></ul><ul><li>We never get things right the first time </li></ul>
  25. 25. Better code .. code/review - 9 <ul><li>When To Refactor .. </li></ul><ul><li>Before you add new functionality </li></ul><ul><li>Refactor until it becomes obvious how to add a feature </li></ul><ul><li>When you don't understand the code </li></ul><ul><li>Make code more readable </li></ul><ul><li>When you fix a bug </li></ul><ul><li>After a code review </li></ul>
  26. 26. Better code .. code/review - 10 <ul><li>xUnit Framework for PHP </li></ul><ul><li>PHPUnit ( </li></ul><ul><li>SimpleTest ( </li></ul><ul><li>Not only for object-oriented code </li></ul><ul><li>If you don't have tests, create them as you go </li></ul><ul><li>At least, run a Lint check: </li></ul><ul><ul><li>php -l <filename> </li></ul></ul><ul><ul><li>find ./ -type f -name *.php -exec php -l {} ; | grep &quot;Errors parsing &quot;; //-not -regex '.*/.svn/*.*' </li></ul></ul>
  27. 27. Better code .. code/review - 11 <ul><li>Tools :- </li></ul><ul><li>1.Trac </li></ul><ul><li>2.php_beautifier[php_beautifier -l &quot;Pear(add_header=apache) ArrayNested() ListClassFunction()&quot; index.php index_new.php] </li></ul><ul><li>3.phpcpd </li></ul><ul><li>4.phploc[phploc --count-tests /usr/local/src/ezcomponents/trunk/Workflow] </li></ul><ul><li>5.phpdcd </li></ul><ul><li>6.phpmd [phpmd /path/to/source text codesize,unusedcode,naming] </li></ul><ul><li>7.statsvn[java -jar statsvn.jar searchAgents/logfile.log searchAgents/ -output-dir svnreport/] </li></ul>
  28. 28. Better code .. code/review - 12 <ul><li>Always check Performance … </li></ul><ul><li>YSlow (Firefox) </li></ul><ul><li> PageSpeed (Firefox) </li></ul><ul><li> Firebug (Firefox) </li></ul><ul><li> HTTPWatch (Firefox & IE) </li></ul><ul><li> Dynatrace Ajax Edition (IE only, Firefox beta) </li></ul><ul><li>xdebug </li></ul><ul><li>netstat -antp | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn </li></ul><ul><li>ps -e -o vsz | awk '{size += $1}END{print(size)}' </li></ul><ul><li>mpstat -P ALL 5 </li></ul><ul><li>vmstat 5 </li></ul>
  29. 29. Summary <ul><li>We look at things like:- </li></ul><ul><li>coupling </li></ul><ul><li>cohesion </li></ul><ul><li>thread safety (if threads were used) </li></ul><ul><li>Boundary Conditions (what is going into and out of a method is what you expect e.g. no nulls) </li></ul><ul><li>Code style follows company standards </li></ul><ul><li>Code is not duplicated or copied (this can be automated Google for Simian) </li></ul><ul><li>Code complexity - Google cyclomatic complexity </li></ul><ul><li>Will the code that has been written cause any knock ons in other parts of the system </li></ul><ul><li>If class, method and variable names are kept meaningful a lot of comments should not be necessary </li></ul><ul><li>Is exception handling in place and comply with company standard </li></ul><ul><li>There are Unit Tests for the code that are meaningful and the tests are relevant </li></ul><ul><li>Logic errors </li></ul><ul><li>Conformance to the specification (you have one of those, right?) </li></ul><ul><li>Robustness/defensive programming </li></ul><ul><li>Failure notification </li></ul>
  30. 30. Thank You <ul><li>Resourses/Links: </li></ul><ul><li> </li></ul><ul><li> </li></ul><ul><li> </li></ul><ul><li> </li></ul><ul><li> </li></ul><ul><li> </li></ul><ul><li> </li></ul><ul><li> </li></ul><ul><li> </li></ul><ul><li> </li></ul><ul><li> </li></ul><ul><li> </li></ul><ul><li> </li></ul>