Refacturing is a natural process, usually projects grow over time and then and when this naturally grown jungle needs to get urbanized again to make it a nice place to live. This process is usually accompanied from (sometimes loud and rude) discussions about [[Philosophy and holy Wars]], but don't worry: dogs that make noise usually don't bite. Revolutionary ideas sometimes need some fighting to get through.

+

Refacturing is a natural process, usually projects grow over time and then and when this naturally grown jungle needs to get urbanized again to make it a nice place to live. This process is usually accompanied by (sometimes loud and rude) discussions about [[Philosophy and holy Wars]], but don't worry: dogs that make noise usually don't bite. Revolutionary ideas sometimes need some fighting to get through.

Since with time developers get a little blind and used to their own weaknesses it makes sense that reviewer/refactorer and programmer are not the same person. No part of the Linux kernel is exclusively owned by a maintainer. If a new solution makes sense it will make it sooner or later into the public source tree.

Since with time developers get a little blind and used to their own weaknesses it makes sense that reviewer/refactorer and programmer are not the same person. No part of the Linux kernel is exclusively owned by a maintainer. If a new solution makes sense it will make it sooner or later into the public source tree.

Revision as of 22:35, 24 September 2004

What is Refactoring?

You find a short definition of the Refactoring Process on Wikipedia, mentioning the important facts. The basic principles are:

Simplify your Code.

Don't introduce new Features in the Refactoring Process.

Break down API Barriers where they don't make Sense

Introduce new Interfaces where they stabilize your Code.

Try to keep APIs to external Interfaces as stable as possible.

Simplify your Code.

Refacturing is a natural process, usually projects grow over time and then and when this naturally grown jungle needs to get urbanized again to make it a nice place to live. This process is usually accompanied by (sometimes loud and rude) discussions about Philosophy and holy Wars, but don't worry: dogs that make noise usually don't bite. Revolutionary ideas sometimes need some fighting to get through.

Since with time developers get a little blind and used to their own weaknesses it makes sense that reviewer/refactorer and programmer are not the same person. No part of the Linux kernel is exclusively owned by a maintainer. If a new solution makes sense it will make it sooner or later into the public source tree.

Keep it Simple

The simpler the resulting code is the easier it will be to maintain. Even from the performance point of view simple code is almost always preferable.

If you want to see some impressive code following this approach you may want to check out one of Fabrice Bellards Projects, e.g. TinyGL or the ID software GPL games Doom, Quake & Co Great to learn performant and compact Coding.

So please: Whatever you do, keep it simple.

Please do never ever apply big Changes in-place

If you plan to rewrite bigger portions of the code please don't create a huge patch or thousands of patches but fork the relevant code modules so that people can easily test them concurrently with the old code and are free to use the old, usually well-tested code until your new version has matured.

There have been several situations in the past where the linux-dvb CVS was barely usable for weeks or months because we did not followed this principle. Please respect that other people are using the linux-dvb source in productive environments and rely on a working code base.