Extensibility

When mod­i­fy­ing a sys­tem (such as adding fea­tures), one should be con­cerned about the abil­i­ty of the sys­tem to be mod­i­fied. This im­plies the pres­ence of two ex­ten­si­bil­i­ty as­pects: ar­chi­tec­tur­al and qual­i­ty-cen­tered. I be­lieve it is es­sen­tial to un­der­stand the dif­fer­ence be­tween those two as­pects, es­pe­cial­ly in or­der to de­ter­mine what are the most ap­pro­pri­ate so­lu­tion.

Ar­chi­tec­tur­al ex­ten­si­bil­i­ty

The is­sue of­ten en­coun­tered when de­vel­op­ing a sys­tem larg­er than two men-months is that the orig­i­nal ar­chi­tec­ture is un­able to en­com­pass some new fea­ture. It just wasn't done for that, and now that the fea­ture ex­ists in the back­log, de­vel­op­ers are won­der­ing how could they bend the ex­is­tent prod­uct to be able to add the re­quest­ed fea­ture.

The im­me­di­ate so­lu­tion here is high-lev­el refac­tor­ing. By high-lev­el refac­tor­ing, I mean all those changes which deal pre­cise­ly with ei­ther ar­chi­tec­ture—if the team is able to change the ar­chi­tec­ture, or high-lev­el de­sign. By com­par­i­son, low-lev­el refac­tor­ing is about to re­name meth­ods or trans­form switch block into in­her­i­tance. Note that both are cru­cial, so high-lev­el refac­tor­ing is not more im­por­tant than low-lev­el one.

Also worth not­ing, two tech­niques help to ei­ther avoid is­sues with such ex­ten­si­bil­i­ty, or to re­duce the pain of do­ing ma­jor changes in ar­chi­tec­ture:

• Prop­er ar­chi­tec­ture helps a lot. Not think­ing about ar­chi­tec­ture and let the prod­uct grow or­gan­i­cal­ly may be a fast so­lu­tion, but usu­al­ly cre­ates painful sit­u­a­tions where large chunks of the code base should be mod­i­fied in or­der to ac­com­mo­date new fea­tures. If the ar­chi­tec­ture is thought thor­ough­ly from the be­gin­ning, it doesn't mean new fea­tures would in­te­grate seam­less­ly (al­though much more of them would), but nev­er­the­less, ar­chi­tec­tur­al changes would be less painful to do, with few­er side ef­fects.

  The lack of cas­cad­ing changes (or few­er of them) is by the way cru­cial here: when adding a fea­ture, you want to avoid cas­cad­ing changes at all costs, since those ones are not only par­tic­u­lar­ly ex­pen­sive, but also can kick out the team who will spend more time adapt­ing their work to the changes than to do some­thing use­ful.

• Con­tin­u­ous refac­tor­ing, es­pe­cial­ly at high lev­el, makes it pos­si­ble to keep the sys­tem ready for fur­ther changes, as well as en­sur­ing that the parts of the sys­tem have enough iso­la­tion from each oth­er. Iso­la­tion keeps cas­cad­ing changes low too.

Qual­i­ty-cen­tered ex­ten­si­bil­i­ty

This is the is­sue which is en­coun­tered more when ex­tend­ing a lega­cy code base. For ex­am­ple, a de­vel­op­er is asked to add a sim­ple fea­ture to an ap­pli­ca­tion, but spends weeks im­ple­ment­ing it, be­cause a slight change to one part of the code base breaks some­thing in a dif­fer­ent part which looks com­plete­ly un­re­lat­ed. Here, the prob­lem is not the ar­chi­tec­ture—it can be to­tal­ly adapt­ed to the new change, but rather the qual­i­ty of the code it­self.

The is­sues can be mul­ti­ple: the lack of prop­er test­ing with enough code cov­er­age, the ab­sence of com­mon style, the lack of doc­u­men­ta­tion, etc.

The im­me­di­ate so­lu­tion is low-lev­el refac­tor­ing, as well as deal­ing with the real is­sue be­fore adding the fea­ture.

• Low-lev­el refac­tor­ing can be very un­ob­tru­sive and lo­cal, but can also cas­cade quite fast. Say we want to re­place those ugly if/elseif/elseif/elseif/else blocks by in­her­i­tance, but to do that, we should first iso­late the com­mon log­ic, giv­en that those if/.../else blocks are repli­cat­ed in four files. For that, we need to cre­ate a base class, but this would mean that we should mod­i­fy the class hi­er­ar­chy, since one of those four class­es in­her­its from a class which is com­plete­ly un­re­lat­ed. A week lat­er, we are still refac­tor­ing.

• Deal­ing with the real is­sue can be some­times easy, but usu­al­ly is hard as hell. For ex­am­ple, if the ap­pli­ca­tion lacks test­ing, the pri­ma­ry task be­fore adding fea­tures is to add tests, but to do it, one should make the code pos­si­ble to test. This is most­ly chick­en or the egg prob­lem: be­fore split­ting a 5 000 LOC method, you should unit-test it to avoid re­gres­sions, but in or­der to unit-test it, you should split it first.

Again, two long-term tech­niques to avoid such is­sues:

• Con­tin­u­ous refac­tor­ing, es­pe­cial­ly at low lev­el. I don't think this needs to be ex­plained any fur­ther.

• Deal­ing with tech­ni­cal debt by en­forc­ing com­mon style, hav­ing tests, doc­u­men­ta­tion, etc. No need to de­tail this ei­ther.