the Design Experience Weblog Archive

  Courier

  Courier-Bold

  Courier-BoldOblique

  Courier-Oblique

  Helvetica

  Helvetica-Bold

  Helvetica-BoldOblique

  Helvetica-Oblique

  Symbol

  Times-Bold

  Times-BoldItalic

  Times-Italic

  Times-Roman

  ZapfDingbats>

This is another simple idea that I often overlook. At least it validates my idea that I should learn more of the fundamentals of computer science to become a better programmer.

The article also stresses revisiting the fundamentals after awhile. This can bring new insights as you apply everything else you have learned back into understanding how the fundamentals apply.

In many places within OpenACS its almost impossible to write a test that works on just one procedure. Often you have to build up a huge amount of data before you can test anything. Developers have found there are places in OpenACS that are difficult to extend without irrecovably forking and getting oneself into a maintenance nightmare.

I suggest that the places that are hard to test, or to modify/maintain are the same code. This idea is pretty apparent once you try to write a test.

The magic comes when you refactor the code to make it easier to test. Seems that easier to test is also easier to debug and use. This is where test-driver design comes in of course. Whether you write the tests right before or during design of your API really doesn't matter as much as the learning that comes from noticing your API is horribly difficult to write a test for. When you are not yet committed to thousands of lines of code relying on your API, refactoring for testability is low risk, and no problem.

I also ran across the closely related two radical ideas of Agile

1. it's okay - indeed, it's better - to "re-design" the code so that testing is easier;
2. the changes for testability are now part of the system under test, and will be shipped to the user.

Amazingly simple, but also revolutionary to many programmers, including myself.