C[omp]ute

From: "Milan Maksimovic" <maksa@...>

Date: Fri, 30 Jan 2004 07:53:29 +0100

Sorry if this list is just meant for us to post interesting stuff that we
find, but I have to follow up on this. 

>> The "standard" refactoring book is probably -
>> http://www.amazon.com/exec/obidos/tg/detail/-/0201485672 
>> - it's OK, but mostly obvious (like basic pattern books, really)

 For very thoughtful people with enough experience it is probably 'mostly
obvious' and 'basic', but for others it is a nice shortcut to get there (or
closer to that). For me it was far more then 'OK'. Back in 1999 when I first
read it I just got out of maintaining a pretty big and pretty poorly written
legacy C++ Windows application. I can still remember the pain, which was
mostly caused by my total unpreparednes for 1200-line functions
copied/pasted/changed-just-a-bit, 200+ Kb CPP files, pseudo-object and
pseudo-procedural code, and similar horrors I inherited. I understood that
things were very wrong somehow, but I didn't really have very clear ideas on
how to go about them. On some places I instinctively factored out my things
and tried to put new functionality in classes separate from the Tar Pit, but
in some places I didn't and it hurt. The sheer amount of things was
imobilizing my very small cerebrum. I wish I did better there. Some people
get it without external help of any kind, some need books to tell them. I
wish I was in the first camp, but I'm still glad that there are books out
there.

 The Refactoring book drastically changed the way I think about (both my and
other people's) code, and the first thing that always comes to my mind when
I think about it is - "I wish I read this sooner. Oh how I wish.". 

 A meager attempt to stay on topic follows: by following the advice found in
that book, after a while I realized that as a side effect void member
functions started appearing far, far less in my classes (I still don't live
in a functional programming world), which automatically meant less state,
and less state is good. Which in it's extreme form leads us to FP - less
state (actually - no state) is partially what functional programming is
about. 

 From what I've seen so far in this industry (not saying that I've seen
much), I don't know many people (in fact, I met none so far) that didn't
need this book to some extent. Some need it more, some need it less, and if
everybody that is in some way involved with code of any kind read it and
understood it, this would be a far happier programming world. It sure did
help me a lot, and ever since then I (almost fanatically ;) read everything
written by Martin Fowler and it never fails to teach me valuable things.


Regards,
M.