Refactoring

From Apache OpenOffice Wiki
Revision as of 12:34, 27 June 2007 by Np (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

When to Refactor - a Guideline

Refactorings During Daily Work

One of the ideas of Code Reviews is that the OpenOffice.org code base will improve gradually, step by step, during daily work. To reach that goal, continuous little code improvements during other tasks are needed. To meet also short term quality-goals, not every refactoring can be done at any time.

Categories of Refactorings

This is mainly a question of common sense, the following just provides the overall idea. Don't count lines to decide, if a refactoring is "middle" or "major".

Minimal refactorings

that

  • affect only the code one would touch anyway for the actual task
  • and have a negligible risk

are always desired and allowed.

All other refactorings may happen only on development code lines (like currently SRC680), but not on release branches (like OOF680).

Middle Refactorings

that

  • are not larger than about 1/3 of the code changed for the actual tasks
  • may cause some, but not extremely high, risk

can be done on the fly in the same CWS with other tasks. If they affect other parts of the product than the actual tasks, document this in an extra task, so the QA knows what needs to be tested additionally. Keep your I-team (especially the QA member) informed!

Major Refactorings

that

  • are huge
  • or carry an extraordinary risk

should be done in dedicated CWSs.

Personal tools