Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

How Libraries Evolve. A Survey of Two Industrial Companies and an Open-Source Community (APSEC'22)

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Wird geladen in …3
×

Hier ansehen

1 von 36 Anzeige

Weitere Verwandte Inhalte

Aktuellste (20)

Anzeige

How Libraries Evolve. A Survey of Two Industrial Companies and an Open-Source Community (APSEC'22)

  1. 1. How Libraries Evolve: A Survey of Two Industrial Companies and an Open-Source Community 1CIRAD, UMR - SENS, Montpellier, France 2Arolla, Paris, France 3Univ. Lille, Inria, CNRS, Centrale Lille, UMR 9189 - CRIStAL Oleksandr ZAITSEV1, Stéphane DUCASSE 3, Nicolas ANQUETIL 3, Arnaud THIEFAINE 2 29th Asia-Pacific Software Engineering Conference (APSEC 2022) oleksandr.zaitsev@cirad.fr
  2. 2. 2 Arolla is a consulting company specialised in the advanced techniques of software development: Clean Code, TDD, BDD, Legacy Remediation, etc. https://www.arolla.fr/
  3. 3. Introduction Part 1:
  4. 4. 4 Library Evolution & Update Client System Library v1.0 Client Developer Library Developer depends Part 1 / 5
  5. 5. 5 Client System Library v1.0 Library v2.0 Client Developer Library Developer depends Library Evolution Library Evolution & Update Part 1 / 5
  6. 6. 6 Client System Library v1.0 Library v2.0 Client Developer Library Developer depends Library Evolution ! Errors! Library Evolution & Update Part 1 / 5
  7. 7. 7 Updated Client System Client System Library v1.0 Library v2.0 Client Developer Library Developer depends Library Evolution Library Update Library Evolution & Update Part 1 / 5
  8. 8. 8 Updated Client System Client System Library v1.0 Library v2.0 Client Developer Library Developer depends Understanding the Developers Part 1 / 5 Tools to support client developers Tools to support library developers
  9. 9. 9 Updated Client System Client System Library v1.0 Library v2.0 Client Developer Library Developer depends ‣ How do they behave in the context of library update? ‣ What problems do they face? ‣ What support do they need? Understanding the Developers Part 1 / 5
  10. 10. State of the Art Part 2:
  11. 11. 11 Technique Perspective Client developer Library developer Both Developer survey Code analysis SOTA: Criteria Part 2 / 5
  12. 12. 12 Paper Survey Code Analysis Client Dev. Library Dev. [Robbes 2012a] X ✓ ✓ X [Jezek 2015] X ✓ ✓ ✓ [Hora 2015] X ✓ ✓ X [Bogart 2016] ✓ X ✓ ✓ [Sawant 2016] X ✓ ✓ X [Xavier 2017a] X ✓ ✓ ✓ [Xavier 2017b] ✓ X X ✓ [Hora 2018] X ✓ ✓ X [Kula 2018a] ✓ ✓ ✓ X [Kula 2018b] X ✓ X ✓ [Brito 2019] ✓ X ✓ ✓ SOTA: Empirical Studies Part 2 / 5
  13. 13. 13 1. Most surveys analyse specific cases of breaking changes. 2. No survey has asked client developers about what makes library update hard and what makes it easy. SOTA: Shortcomings Part 2 / 5
  14. 14. Survey Setup & Population Part 3:
  15. 15. 15 Research Questions Part 3 / 5 How do they perceive the impact of library evolution on their clients? Why do they introduce breaking changes? How motivated are they to support their clients? How do they help their clients to update? How do they perceive the impact of library evolution on their systems? What makes library update easy and what makes it hard? RQ1. RQ2. RQ3. RQ4. RQ5. RQ6. Library Developers Client Developers
  16. 16. 16 Pharo (open-source) Pure object-oriented programming language designed in tradition of Smalltalk. It is also an IDE developed entirely in itself. Why? We are members of this community and have access to developers Communities Part 3 / 5 Arolla (industry) Medium-size software consulting company - each dev. has their own project Berger-Levrault (industry) Medium-size software company - dev. work in teams Why? We collaborate with both companies and they agreed to participate
  17. 17. 17 Open-Source (33) Industry (14) Unspecified (8) Library developers (18) 11 5 2 Client Developers (37) 22 9 6 participation was optional; surveys were shared through community chats and forums Developer Population Part 3 / 5 ?
  18. 18. 18 Q: What software they develop? Library Developers Part 3 / 5 Q: What is their level of expertise? Expert Advanced Intermediate Beginner Absolute novice 5 9 3 0 0 Library Framework SDK Microservices Other 15 10 4 4 3
  19. 19. 19 Libraries and frameworks Web (back end) Web (front end) Desktop applications IDE Compilers / VM Mobile applications Embedded systems Security Other Q: What software they develop? Client Developers 22 Part 3 / 5 21 16 12 9 6 4 2 2 5 Q: What is their level of expertise? Expert Advanced Intermediate Beginner Absolute novice 8 18 6 2 0
  20. 20. Survey Results Part 4:
  21. 21. 21 Q: Do you think that breaking changes in your releases have big impact on clients? RQ1. Perception of impact Very small impact Small impact Moderate impact Big impact Very big impact 1 0 9 6 2 Part 4 / 5 Library Dev. Less than an hour Half a day One day Several days A week or more 3 7 4 3 1 Q: How much time do you think client developers need to update to the new version of your library?
  22. 22. 22 RQ2. Why introduce BC? Part 4 / 5 Library Dev. Q: What are your primary reasons for introducing breaking changes? Implementing a new feature API simpli fi cation Improving maintainability Bug fi xing Other 12 11 6 11 2 This confirms the results of [Brito et al., 2019]
  23. 23. 23 Q: How important is it for you to maintain backward compatibility? RQ3. Motivation to support clients Not important at all Of little importance Of average importance Very important Absolutely essential 1 8 5 4 0 Part 4 / 5 Library Dev. Not important at all Of little importance Of average importance Very important Absolutely essential 0 8 4 5 1 Q: How important is it for you to encourage clients to update to the latest version?
  24. 24. 24 RQ4. How do they support clients? Part 4 / 5 Library Dev. Q: When you are forced to break backward compatibility, what do you do to reduce the negative impact on users? (open question) Practice mentioned dev. Documentation 8 Deprecation 4 Automation 4 Communication 3
  25. 25. 3x a year or more often Twice a year Once a year Less often We do not do it regularly 25 Q: How much time does it usually take you to update your dependencies? RQ5. Perception of impact Less than an hour Half a day One day Several days One week or more 17 10 3 3 1 Part 4 / 5 Client Dev. 9 11 6 9 3 Q: Try to estimate how often do you have to deal with the task of updating dependencies?
  26. 26. 26 RQ6. What makes it easy/hard? Part 4 / 5 Client Dev. Q: What makes library update easy? Q: What makes it hard? Factor dev. Documentation 15 Absence of breaking changes 11 Test coverage 6 Tool support 5 Deprecations 4 Simple breaking changes 4 Community support 3 Factor dev. Breaking changes 11 Absent or bad documentation 10 Indirect dependencies 7 Big changes to the API 7 Poor test coverage 4 Removed functionality 3 Changed hooks or abs. classes 3
  27. 27. 27 Library Developers Client Developers ‣ Often have to deal with the problem of library update ‣ Need documentation and support for breaking changes ‣ Want to help their clients to update Key Takeaways Part 4 / 5
  28. 28. Conclusion Part 5:
  29. 29. Contributions 29 Part 5 / 5 ✓ Surveys of library and client developers from different communities. ✓ We are the first to ask client developers what is the support that they need ✓ We confirmed the results of previous studies on the motivation of library dev. to introduce breaking changes and understanding of their impact.
  30. 30. Threats to Validity 30 Internal External Construct ‣ General questions ‣ Only Pharo has transforming deprecations ‣ Some developers answered both surveys Part 5 / 5 Conclusion ‣ Some participants know us and our research ‣ Relatively small size of libraries (no more than 500 clients) ‣ Some RQ can not be expressed as survey questions ‣ Most questions have the list of options ‣ Client perception depends on how the library is used ‣ Relatively small population size ‣ No statistical tests. Only descriptive statistics
  31. 31. ✓ Surveys of library and client developers from different communities. ✓ We are the first to ask client developers what is the support that they need ✓ We confirmed the results of previous studies on the motivation of library dev. to introduce breaking changes and understanding of their impact. Summary Contributions: Updated Client System Client System Library v1.0 Library v2.0 Client Developer Library Developer depends Key takeaways: • Often have to deal with the problem of library update • Need documentation and support for breaking changes • Want to help their clients to update Client Developers Library Developers
  32. 32. Threats to Internal Validity 33 Support • We asked about general experience, not specific projects. (hard to analyse the context that originate certain situations / decisions) • Some questions were hard to answer generally (e.g., how much time it takes for clients to update) • The transforming deprecations mechanism may have affected how Pharo developers answered this survey. • Some developers could have answered both surveys.
  33. 33. Threats to External Validity 34 Support • Some participants could know us personally and be aware of our research (for convenience, we enlisted developers from the open-source community that we are part of and companies that we collaborate with) • Relatively small size of libraries: no more than 500 clients (this is also a novelty because most related works focus only large libraries which might introduce a bias)
  34. 34. Threats to Construct Validity 35 Support • Some research questions could not be fully expressed with survey questions (e.g., to measure the impact of library evolution, we ask how clients perceive this impact and how much time it takes to update) • Most questions were not open but based on the list of options. • The perception of the impact of breaking changes may tell us about the way client uses the library rather than the actual impact
  35. 35. Threats to Conclusion Validity 36 Support • Population size is relatively small — 18 library and 37 client developers (comparable to other surveys in this field: 28 dev., 7 dev., 16 dev., 102 dev.) • Did not perform statistical tests and drew conclusions from descriptive stats. (because of the small population size)

×