Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Treating Code Quality as a First Class Entity (icsme15) [doc. symposium]

Treating Code Quality as a First Class Entity (icsme15) [doc. symposium]

Slides from doctoral symposium of ICSME 2015. Vision on the future of software quality

9847702de1f7f19db8c3e158325baa8e?s=128

Yuriy Tymchuk

September 28, 2015
Tweet

Transcript

  1. Treating Code Quality as a First Class Entity Yuriy Tymchuk

    R A E E L V Supervisor: Michele Lanza
  2. @yuriy_tymchuk Treating Code Quality as a First Class Entity R

    A E E L V Supervisor: Michele Lanza
  3. @yuriy_tymchuk Treating Code Quality as a First Class Entity R

    A E E L V Supervisor: Michele Lanza How can development tools help to ensure a good quality of code during the evolution of a software system?
  4. Code Quality

  5. Code Quality How easy it is to understand modify test

    the software ISO/IEC, ISO/IEC 9126. Software Engineering – Product quality 6.5. ISO/IEC, 2001 (maintainability)
  6. Code Review A. Bacchelli, C. Bird. Expectations, outcomes, and challenges

    of modern code review. In Proceedings of ICSE’13, pp. 712–721, IEEE, 2013
  7. Code Review Tools Y. Tymchuk, A. Mocci, and M. Lanza.

    Code Review: Veni, ViDI, Vici. In Proceedings of SANER’15, pp. 151-160, IEEE, 2015
  8. Visual Design Inspection Y. Tymchuk, A. Mocci, and M. Lanza.

    Code Review: Veni, ViDI, Vici. In Proceedings of SANER’15, pp. 151-160, IEEE, 2015
  9. Y. Tymchuk, A. Mocci, and M. Lanza. Code Review: Veni,

    ViDI, Vici. In Proceedings of SANER’15, pp. 151-160, IEEE, 2015 Y. Tymchuk, A. Mocci, and M. Lanza. Vidi: The Visual Design Inspector. In Proceedings of ICSE’15, to be published, IEEE, 2015
  10. Y. Tymchuk, A. Mocci, and M. Lanza. Code Review: Veni,

    ViDI, Vici. In Proceedings of SANER’15, pp. 151-160, IEEE, 2015 Y. Tymchuk, A. Mocci, and M. Lanza. Vidi: The Visual Design Inspector. In Proceedings of ICSE’15, to be published, IEEE, 2015
  11. None
  12. Package Class Method

  13. Package Class Method More Critics Less Critics

  14. None
  15. None
  16. Quality Rules

  17. Source Code

  18. Critics

  19. None
  20. None
  21. None
  22. ViDI is …

  23. Disconnected from Development

  24. QualityAssistant

  25. None
  26. Pharo 4: patches / months ≈ patches/day 1726 12 5

    Pharo 5: patches / months ≈ patches/day 1071 5 7
  27. Pharo 4: patches / months ≈ patches/day 1726 12 5

    Pharo 5: patches / months ≈ patches/day 1071 5 7
  28. vs Is the importance of a critic related to a

    software lifecycle period?
  29. vs Is the importance of a critic related to a

    software lifecycle period? vs
  30. Issues of Quality Rule Checkers B. Johnson, Y. Song, E.

    Murphy-Hill, and R. Bowdidge. Why don’t software developers use static analysis tools to !nd bugs?
 In Proceedings of ICSE’13, pp. 672–681, IEEE, 2013
  31. Issues of Quality Rule Checkers B. Johnson, Y. Song, E.

    Murphy-Hill, and R. Bowdidge. Why don’t software developers use static analysis tools to !nd bugs?
 In Proceedings of ICSE’13, pp. 672–681, IEEE, 2013
  32. Issues of Quality Rule Checkers B. Johnson, Y. Song, E.

    Murphy-Hill, and R. Bowdidge. Why don’t software developers use static analysis tools to !nd bugs?
 In Proceedings of ICSE’13, pp. 672–681, IEEE, 2013
  33. Can a critic noise be reduced by dedicated automated resolution?

  34. Can a critic noise be reduced by dedicated automated resolution?

    Noisy rules → auto-"x.
  35. Can a critic noise be reduced by dedicated automated resolution?

    Noisy rules → auto-"x. Analyze the impact
  36. Can a critic noise be reduced by dedicated automated resolution?

    Noisy rules → auto-"x. Analyze the impact
  37. The “Greatest Common Divisor” Way C. Sadowski, J. Gogh, C.

    Jaspan, E. Soederberg, C. Winter. Tricorder: Building a Program Analysis Ecosystem.
 In Proceedings of ICSE’15, pp. 598–608, IEEE, 2015
  38. One Size Fits All L. Renggli, S. Ducasse, T. Gîrba,

    O. Nierstrasz. Domain-speci!c program checking. In Proceedings of TOOLS’10, pp. 213-232, 2010 A. C. Hora. Assessing and Improving Rules to Support Software Evolution. PhD diss., Université Lille 1-Sciences et Technologies, 2014
  39. The Dedicated Rule L. Renggli, S. Ducasse, T. Gîrba, O.

    Nierstrasz. Domain-speci!c program checking. In Proceedings of TOOLS’10, pp. 213-232, 2010 A. C. Hora. Assessing and Improving Rules to Support Software Evolution. PhD diss., Université Lille 1-Sciences et Technologies, 2014
  40. Improving Co-Evolution A. C. Hora. Assessing and Improving Rules to

    Support Software Evolution. PhD diss., Université Lille 1-Sciences et Technologies, 2014
  41. Improving Co-Evolution A. C. Hora. Assessing and Improving Rules to

    Support Software Evolution. PhD diss., Université Lille 1-Sciences et Technologies, 2014
  42. Improving Co-Evolution A. C. Hora. Assessing and Improving Rules to

    Support Software Evolution. PhD diss., Université Lille 1-Sciences et Technologies, 2014
  43. Improving Co-Evolution A. C. Hora. Assessing and Improving Rules to

    Support Software Evolution. PhD diss., Université Lille 1-Sciences et Technologies, 2014
  44. Rules Should Be Dedicated

  45. Method Class Package Project Rules Should Be Dedicated

  46. Method Class Package Project Dependency Inheritance Rules Should Be Dedicated

  47. Method Class Package Project Dependency Inheritance Organization Team Developer Rules

    Should Be Dedicated
  48. Method Class Package Project Dependency Inheritance Organization Team Developer Rules

    Should Be Dedicated User
  49. Method Class Package Project Dependency Inheritance Organization Team Developer User

    What are the con#icts for dedicated rules of dependent projects?
  50. What are the con#icts for dedicated rules of dependent projects?

    low-level core UI framework BL OC
  51. What are the con#icts for dedicated rules of dependent projects?

    BL OC low-level core UI framework agile visualization framework
  52. What are the con#icts for dedicated rules of dependent projects?

    BL OC low-level core UI framework agile visualization framework
  53. Can deprecation / API changes be enhanced by quality rules?

  54. Can deprecation / API changes be enhanced by quality rules?

    Refactoring → rules. Analyze usage
  55. Can a critic noise be reduced by dedicated automated resolution?

    Can deprecation / API changes be enhanced by quality rules? What are the con#icts for dedicated rules of dependent projects? Is the importance of a critic related to a software lifecycle period? BL OC vs
  56. Can a critic noise be reduced by dedicated automated resolution?

    Can deprecation / API changes be enhanced by quality rules? What are the con#icts for dedicated rules of dependent projects? Is the importance of a critic related to a software lifecycle period? Do developer/teem dedicated rules perform better than generic? Can the cost/value of critic resolution be derived from history? (Dedicated technical debt) BL OC vs
  57. @yuriy_tymchuk Treating Code Quality as a First Class Entity R

    A E E L V Supervisor: Michele Lanza
  58. @yuriy_tymchuk Treating Code Quality as a First Class Entity R

    A E E L V Supervisor: Michele Lanza In order to build helpful software quality tools, we need an underlying model that 1) facilitates “smart” rules (that aid in critic resolution) 2) allows adaptation of rules for a speci"c scope 3) is aware of software scopes and lifecycle