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

Yuriy Tymchuk

September 28, 2015
Tweet

More Decks by Yuriy Tymchuk

Other Decks in Programming

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 How can development tools help to ensure a good quality of code during the evolution of a software system?
  3. 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)
  4. Code Review A. Bacchelli, C. Bird. Expectations, outcomes, and challenges

    of modern code review. In Proceedings of ICSE’13, pp. 712–721, IEEE, 2013
  5. 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
  6. 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
  7. 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
  8. 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
  9. Pharo 4: patches / months ≈ patches/day 1726 12 5

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

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

    software lifecycle period? vs
  12. 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
  13. 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
  14. 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
  15. Can a critic noise be reduced by dedicated automated resolution?

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

    Noisy rules → auto-"x. Analyze the impact
  17. 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
  18. 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
  19. 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
  20. Improving Co-Evolution A. C. Hora. Assessing and Improving Rules to

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

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

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

    Support Software Evolution. PhD diss., Université Lille 1-Sciences et Technologies, 2014
  24. Method Class Package Project Dependency Inheritance Organization Team Developer User

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

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

    BL OC low-level core UI framework agile visualization framework
  27. 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
  28. 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
  29. @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