Code quality

1,015 views

Published on

Improve code quality

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

Code quality

  1. 1. Pains <ul><li>Oncall at midnight
  2. 2. Build failed
  3. 3. Dozens of defects
  4. 4. Hard to fix
  5. 5. Introduce new defects
  6. 6. ... </li></ul>
  7. 7. Problem — Poor Quality <ul><li>Poor unit test coverage
  8. 8. Complexity for integration test
  9. 9. No full regression (100%)
  10. 10. Tight couplings
  11. 11. ... </li></ul>
  12. 12. Execuses <ul><li>Limited time
  13. 13. High system complexity
  14. 14. Hard to write unit test
  15. 15. Long cycle to identify bugs and deliver fix
  16. 16. ... </li></ul>
  17. 17. Gains <ul><li>Unit Test
  18. 18. Integration Test
  19. 19. Regression Test
  20. 20. Code Coverage
  21. 21. ... </li></ul>
  22. 22. What a manager do? <ul><li>Define the problem
  23. 23. Break it down
  24. 24. Identify boundary
  25. 25. Keep &quot;fool&quot;
  26. 26. Measure it
  27. 27. Bad smell(Can we be better)?
  28. 28. ... </li></ul>
  29. 29. What we do in Scrum? <ul><li>Define (and pickup) user story
  30. 30. Break story into tasks
  31. 31. Assign task to owner
  32. 32. Identify dependency
  33. 33. Testing
  34. 34. Sprint review </li></ul>
  35. 35. What we do in code? <ul><li>Define the function
  36. 36. Break it down
  37. 37. Encapsulation
  38. 38. Black box
  39. 39. Test it
  40. 40. Bad smell(Potential bugs)?
  41. 41. ... </li></ul>
  42. 42. What we do in Unit Test? <ul><li>Exactly describe use case (TDD?)
  43. 43. Mockup &quot;external&quot; access
  44. 44. Focus on own &quot;Unit&quot;
  45. 45. Verify business &quot;Logic&quot;
  46. 46. Cover all public interfaces </li></ul>
  47. 47. What we do in Integration Test? <ul><li>Extractly describe use case
  48. 48. Use real external resource/interface
  49. 49. Focus on both business logic and accessbility between systems
  50. 50. Cover &quot;own&quot; public interface </li></ul>
  51. 51. A real case
  52. 52. A real case <ul><li>Unit Test and Integration Test are sharing same test code (business logic)
  53. 53. They have different configurations(IOC)
  54. 54. Not only &quot;Happy pass&quot;, remember cover exception </li></ul>
  55. 55. Code review and commit <ul>Developer <li>Run regression test suite (UT + IT)
  56. 56. Run FindBugs
  57. 57. Fix bugs
  58. 58. Submit code review
  59. 59. Wait until review is finished
  60. 60. Commit </li></ul><ul>Reviewer <li>Download patch
  61. 61. Run UT suite
  62. 62. Run FindBugs
  63. 63. Review code
  64. 64. Comments/bugs if any
  65. 65. Finish Review </li></ul>
  66. 66. Can we do better? <ul>Useful tools <li>FindBugs
  67. 67. http://findbugs.cs.umd.edu/eclipse/
  68. 68. Eclemma code coverage tools
  69. 69. http://update.eclemma.org/
  70. 70. Google CodePro
  71. 71. http://dl.google.com/eclipse/inst/codepro/latest/3.6 </li></ul>
  72. 72. Encapsulate external dependencies <ul><li>Create Proxy, Delegate or Wrapper classes to encapsulate external dependencies
  73. 73. Implement the interface which represent our own requirement by this encapsulator.
  74. 74. While external interface changes, our own interface will not changes, but the encapsulator changes.
  75. 75. As a result, the client code which calls our own interface need not any changes. </li></ul>
  76. 76. FindBugs
  77. 77. FindBugs
  78. 78. Eclemma - Code Coverage
  79. 79. Eclemma - Code Coverage <ul><li>Help us know what has not been coverred
  80. 80. Help us find bugs
  81. 81. The higher coverage we have, the safer when we do refactory or add new feature </li></ul>
  82. 82. Google CodePro – audit code
  83. 83. Google CodePro – dependencies
  84. 84. Google CodePro - dependencies
  85. 85. Google CodePro - dependencies <ul>Current: Tight couplings with external dependencies </ul>
  86. 86. Google CodePro - dependencies <ul>Better: Encapsulate external dependency </ul>
  87. 87. Any comments?
  88. 88. Thank you!

×