January, 2003 Archive

Sometimes you just don’t want to make a change in the code like that. Some kind of procedure is needed to construct a list of checks, uncertainties etc. The general lessons from refactoring apply in these situations. I’m thinking out creating a refactor sheet which contains an easy to use checklist of form in which developers can entry information on the refactoring task a hand.

This list should at least include:

• goal: what are we trying to improve, a little bit more verbose than fix #bug 49712 is appreciated
• peer review: each refactoring task is performed by two people (at least) . Who’s coding and who’s reviewing is up to the duet
• tests: which tests should be done to check whether goal is reached. (this is actually the most important step)
• solution strategy: refactoring has some well known terms to work with, especially for object oriented systems. Try to classify the refactoring into one of these terms, so an objective reference is available

It would rock if we could use a refactoring browser to make it easier to perform the refactoring.

Note: refactoring is not adding functionality, you go from a working situation to a working situation, not from a broken situation to a (hopefully) working situation.

Pitfalls

refactoring backtrack explosion: suppose you want to fix a bug, the solution is apparent, you fix it, but you recognize the code can be improved by making it more general. You create a refactor sheet for it and start thinking about it. Almost immediately you see that there is a lower level change required to make the top level refactoring viable, so you create another refactoring sheet, pulling in an extra dependency for that refactoring. If this process repeats itself 2 times, you can be sure your code is not othogonal enough. Instead of making the refactorings smaller and smaller until the changes are properly localized and you can start implementing them, you pull in more and more dependencies. The process fall into a deadlock, suddenly you don’t know where to start and you’re not sure which dependencies to check anymore.

If you find yourself in this situation, let the orginal bugfix sit in the code (make a FIXME though!) and go walk the dog. Don’t think about the problem for a while. At a later time, return to the problem and try to solve it at a higher level, not changing API or interfaces, but generally making code more orthogonal without solving the original problem.

What you’re actually doing at that time is converting the system to a new state, so your refactoring stack will be different than the one described above. Naturally you use the knowledge you have about the old stack.

Practical application

How to organize this in real life? Use the bugtracker for the refactoring sheets? It’s a good start. Start simple at least, but make sure information is in a repository (but I say that with all information produced)

In general, the temptation to bring the templating language close to the programming domain is high. It creates a possibility to do all things which the programming language can do as well, often powerfull and most of the time dangerous.

In BL there is some PHP syntax hidden in the tags (for example the evaluation of conditions in if and while constructs).

Here’s a good example why the domain of the blocklayout templating system and the programming language in which it was implemented should be separated.

Because the domain of blocklayout and PHP are so tight together now, this is just one example of what can happen.
Bug 107 – <xar:set> allows PHP to be executed

In calling an API function for a module you had to make sure that the API of that module was loaded in your module. The core had already provisions that if the API was already loaded, it wouldn’t load it again. This can be automated. On calliing an API function (assuming that call is necessary of course) the core can check whether the API is loaded and if not, load the API.

This has the following advantages:

• guaranteed loading of API
• smaller code size
• simplification for module developers

This changeset makes it a lot easier for module developers. They can just use xarModAPIFunc in their modules, without calling xarModAPILoad each time. Basically this lil change does the same as the developer did. Check whether the module API was already loaded, if not load the module API.

All diffs for ChangeSet 1.498

And a client naturally…Once you have the blog server side set up, you obviously need something better than a webform to post the ramblings. Installation of mozblog(http://mozblog.mozdev.org) went with some hickups. I really like the fact of pressing Alt-P, jotting down something and going back to where I was. No separate application, no nothing.We should seriously considering making the mozblog suitable for Xaraya. This kind of blogging is something I can relate to

Always hated blogs, weblogs or whatever those things are called. So I decided to install one ;-) . No deeper thought behind it, just wanted to try MT out, it might even help Xaraya become a better weblog tool. I was however looking for a diary kinda thing and this might help to get things organzed and published at the same time. We’ll see.