steve at lonetwin.net
Fri Dec 3 11:04:17 CET 2010
Just a note in sideways, about my own experience and opinion on this topic ...
On 12/01/2010 04:33 PM, Kenneth Gonsalves wrote:
> I know that this has cropped up in a parallel thread, but anyway I would
> like a new thread on this. In a LUG list a ruby guy made a statement
> that 'No self respecting developer could function without having read
> the refactoring book'. How relevant is this to python? I do not see much
> except years ago something called bicycle repair man - is that still
> used? or is this whole thing buzz?
I've been fortunate enough to work with people who employ one or more of these
'good programming', 'agile' methods to become efficient in the day-to-day
'engineering practice' of programming (as opposed to talking about it like high
nose evolved computer science or using it in a throw away manner for 1 project
for the sake of curiosity / demonstration).
So, I have learned to understand, appreciate and use things like TDD, CI and
perform refactoring without ever reading one book on these things. I am sure,
I'll better understand them if I did read the books but at the end of the day
unless you use these techniques in your regular day-to-day work without
employing short-cuts when they become inconvenient, it really just is mental
Coming to refactoring in particular, in the terms that Fowler defines it, I
think it is just formalization of common sense that most good programmers(*)
already are intuitively aware of. I would risk a guess that the person in this
thread who asserted "A self respecting developer will NOT need to refactor his
code in the first place." is just as inexperienced in 'real world' projects as
the original person who said "No self respecting developer could function
without having read the refactoring book" -- either of these views are extremely
sweeping generalizations about the practice of programming. They are typical of
people who've not faced fast approaching deadlines, while dealing with large
code bases with evolving requirements, eventually led by PHBs or clueless customers.
Most good engineering practices get thrown out of the window under pressure. The
advantage of some of these techniques is to minimize the effect of this reality
(for eg: using TDD and CI) and also make it easier get back on track once the
pressure eases (for eg: using refactoring) <-- real world experience speaking !
random spiel: http://lonetwin.net/
what i'm stumbling into: http://lonetwin.stumbleupon.com/
More information about the BangPypers