[Gajim-devel] #1 Weekly Refactoring Newsletter

Stephan Erb steve-e at h3c.de
Wed Nov 11 20:36:29 CET 2009

Hey everybody,

== What I have done last week(s): ==

I have worked on several smaller issues in many places of our code base.
The highlights are: 
      * Introduced a common super class for Contact and GC_Contact so
        that both can share code. 
      * Contacts now know their associated account. There might still be
        old code doing heavy lifting to work around the missing account
        attribute. This old code can now be removed. 
      * Made it more explicit how we use the Contacts class. Now there
        are several methods to distinguish the creation of certain kinds
        of contacts, e.g. self contacts (other resources of us) 
      * Extracted the Metacontact related methods of Contacts to a
        separate class 
      * Wrote tests for the caps module 
      * Internally refactored the caps module to unify the handling of
        the old and new XEP version 
      * Removed the 'nonexistant' workaround for caps features scattered
        over our codebase by using a feature blacklist to handle those
        special cases 
      * The global caps cache now resides under caps.capscache instead
        of gajim.capscache. This removed the dependency of the caps.py
        on gajim.py 
      * Moved the Interface() class from gajim.py to gui_interface.py 
      * Added a pylint and a build-test script to scripts/dev 
      * Reorganized our tests. Tests requiring network or GTK have been
        moved to a separate module.

== What I encountered ==

Our startup logic is twisted and complex. It involves gajim,
common/gajim and the constructor of the Interface class. It is not
really obvious where we do certain initializations and pre-start actions
(e.g. check that we are the default jabber client).

The problem is tightened by modules which perform actions without
explicitly stating them. Without looking into each module it is not
obvious which dependencies have to be reflected in the import order.

A first step to simplify this could be to make module import
side-effects explicit:

import i18n

instead of just
import i18n

== What I learned ==

It gets worse before it gets better. Sometime you just have to try
something to be able to think about a problem or an area of code more
clearly. Sometimes it is even advisable to throw the refactored code
away and to start again from scratch.

Small incremental steps help to prevent major breakage. 

== What I plan for the next days ==

My current plans are to take another closer look at how we handle and
create contacts. 

Furthermore, vArDo and I will have a closer look at the plugin branch.

Comments and ideas welcome :-)

Best Regards,

More information about the Gajim-devel mailing list