Life After Calc Core Changes
•Télécharger en tant que ODP, PDF•
1 j'aime•446 vues
Slides for the talk I gave at LibreOffice conference 2014, in Bern, Switzerland.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
Similaire à Life After Calc Core Changes
Similaire à Life After Calc Core Changes (20)
Dernier
Dernier (20)
Life After Calc Core Changes
- 1. Life after Calc Core Change Kohei Yoshida <kohei.yoshida@collabora.com>
- 2. Topics • What change was made in Calc core. • Affected areas. • Expectation vs reality. • Going forward.
- 3. What change was made in Calc core. https://libreoffice-from-collabora.com
- 4. ScDocument Old model ScTable ScColumn ScValueCell ScBaseCell Broadcaster (8 bytes) ScFormulaCell Text width (2 bytes) Cell type (1 byte) Script type (1 byte) ScStringCell ScEditCell ScNoteCell*
- 5. New model ScDocument ScTable mdds::multi_type_vector svl::SharedString block double block EditTextObject block ScFormulaCell block ScColumn Broadcaster Text width Script type Cell value
- 6. Iterating over cells (old way)
- 7. Iterating over cells (new way)
- 8. Before shared formula ScFormulaCell ScTokenArray ScFormulaCell ScTokenArray ScFormulaCell ScTokenArray ScFormulaCell ScTokenArray ScFormulaCell ScTokenArray ScFormulaCell ScTokenArray ScFormulaCell ScTokenArray
- 9. After shared formula ScFormulaCell ScTokenArray ScFormulaCell ScFormulaCell ScFormulaCell ScFormulaCell ScFormulaCell ScFormulaCell ScFormulaCellGroup
- 10. Shared string concept svl::SharedStringPool svl::SharedString Original string pool Upcased string pool svl::SharedString svl::SharedString
- 11. String comparison (old way)
- 12. String comparison (new way)
- 13. Bottom line... ● Largest refactoring effort in Calc code. ● Most critical parts of Calc code have changed. ● Shared formula - ScFormulaCell no longer owns ScTokenArray at all times. ● Shared string - all string objects need to be pooled. ● Random access to cell array is no longer O(1).
- 15. Calc 95 %Non-scientific estimate Affected by core change
- 16. What features are affected? Undo / Redo Formula Dependency Reference Updates Copy & Paste Sorting ODS Import / Export Excel Import / Export Named Range Content Rendering Find & Replace Cell Comment Cell Editing Database Range Live Spellcheck VBA API Layer UNO API Layer SYLK Import / Export DBF Import / Export CppUnit Test RTF Import Quattro Pro Import HTML Import / Export External Reference DIF Import / Export Change Tracking CSV Import / Export Conditional Formatting Chart Data Provider Cell Validation Formula Calculation Formula Tokenization Case Conversion Autofilter ...
- 17. Expectation vs Reality https://libreoffice-from-collabora.com
- 18. Check #1 20 to 50% of the code change would cause regressions. Almost all code changes caused regressions in some form. Some did more than others.
- 19. Check #2 The worst part is behind us. We just need to fix trivial bugs. The worst part was yet to come. Lots of medium-to-large follow-up refactoring ensued.
- 20. Check #3 Just focus on regressions during the 4.2 releases, and go back to normal for the 4.3. We did fix the worst ones in the 4.2 cycle. But many still remain.
- 21. Check #4 We already wrote a lot of unit tests for Calc core prior to the change. They should keep us safe. We ended up doubling the amount of unit tests for Calc during the 4.2 period. We still don’t have enough.
- 22. Check #5 As a responsible coder, I will fix all the bugs my change caused. Calc’s core is too large for one coder to handle. We need multiple people who can handle bugs in Calc core.
- 24. Challenges we face ● Squash remainder of regressions caused by the core change. The number still too high. ● Gather more people becoming comfortable handling bug fixes in Calc core. ● Build the culture of writing unit test for each and every bug fix.
- 25. Unit test is key ● One unit test is worth 20 future bug fixes. ● A bug fix does not finish until you write a test. ● Writing unit test is courtesy for your fellow developers. ● We really don’t have a choice.
- 26. Unit test is key (repeated) ● A bug fix without a unit test WILL GET BROKEN AGAIN in the next release. ● A bug fix with a unit test WILL REMAIN FIXED FOREVER. Which one will be your choice?
Notes de l'éditeur
- Sorting performance Named range update. Database range update. Broken formula dependency tracking.
- Some code needs refactoring to become unit-testable.
- Some bugs require a re-design which may take 1 week or more. Consultancy duty & customer bugs take priority.
- “We really don’t have a choice.” - We don’t have huge QA dedicating to go through every code change or long release cycle devoted to ironing out bugs.