Difference between revisions of "Refactoring plan"
Jump to navigation
Jump to search
| (5 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
{{DevDiscussion}} | |||
<div style="width:75em"> | |||
== Overview == | |||
When we started Inkscape, we began with a codebase with lots of | When we started Inkscape, we began with a codebase with lots of | ||
| Line 6: | Line 8: | ||
resolved. Inkscape has grown rapidly, especially thanks to Google's | resolved. Inkscape has grown rapidly, especially thanks to Google's | ||
Summer of Code program. Unfortunately, while we've gained a lot of new | Summer of Code program. Unfortunately, while we've gained a lot of new | ||
features, it hasn't addressed the underlying | features, it hasn't addressed the underlying issues—and in some cases | ||
has exposed new problems. | has exposed new problems. | ||
| Line 13: | Line 15: | ||
accidental code duplication, unfinished code, obsoleted code, etc. | accidental code duplication, unfinished code, obsoleted code, etc. | ||
What | What does codebase cleanup work entail? The work ranges from | ||
straightforward | straightforward “grunt” work like making some simple code changes to all | ||
files in the codebase, to meatier work like abstracting widely used code | files in the codebase, to meatier work like abstracting widely used code | ||
into a more concise and powerful algorithm, to advanced work such as | into a more concise and powerful algorithm, to advanced work such as | ||
extracting distinct code into independent code packages. | extracting distinct code into independent code packages. | ||
== Objectives and Principles == | |||
=== Objectives === | |||
To boil this down into five high level objectives: | To boil this down into five high level objectives: | ||
# Complete some of the big architectural refactoring efforts | |||
# Reduce source code line count | |||
# Break useful code out into stand-alone libraries | |||
# Increase code stylistic consistency | |||
# Make the codebase more convenient to code in | |||
=== Principles === | |||
Now, architectural reworkings can often risk incur massive breakages | Now, architectural reworkings can often risk incur massive breakages | ||
since fundamental pieces of the code are being changed. In order to | since fundamental pieces of the code are being changed. In order to | ||
minimize this, | minimize this, we would like to suggest the following principles: | ||
# Always keep the tree buildable | |||
# Always keep unit tests passing (and add new unit tests) | |||
# Do major refactorings in small steps | |||
# Hold code review parties with 2–3 others to brainstorm | |||
# Drop copied-in codebases in favor of external dependencies | |||
# Make sure every function you touch has some doxygen comments | |||
</div> | |||
Latest revision as of 08:26, 10 February 2018
Overview
When we started Inkscape, we began with a codebase with lots of potential but with some architectural limitations that we've never quite resolved. Inkscape has grown rapidly, especially thanks to Google's Summer of Code program. Unfortunately, while we've gained a lot of new features, it hasn't addressed the underlying issues—and in some cases has exposed new problems.
Inkscape's also been extremely successful at gaining a lot of contributors, yet this comes with a price: Stylistic differences, accidental code duplication, unfinished code, obsoleted code, etc.
What does codebase cleanup work entail? The work ranges from straightforward “grunt” work like making some simple code changes to all files in the codebase, to meatier work like abstracting widely used code into a more concise and powerful algorithm, to advanced work such as extracting distinct code into independent code packages.
Objectives and Principles
Objectives
To boil this down into five high level objectives:
- Complete some of the big architectural refactoring efforts
- Reduce source code line count
- Break useful code out into stand-alone libraries
- Increase code stylistic consistency
- Make the codebase more convenient to code in
Principles
Now, architectural reworkings can often risk incur massive breakages since fundamental pieces of the code are being changed. In order to minimize this, we would like to suggest the following principles:
- Always keep the tree buildable
- Always keep unit tests passing (and add new unit tests)
- Do major refactorings in small steps
- Hold code review parties with 2–3 others to brainstorm
- Drop copied-in codebases in favor of external dependencies
- Make sure every function you touch has some doxygen comments