Am 13.01.2014 21:00, schrieb Orchid Win7 v1:

> One of the things that frustrates me about my job is that I want to
> refactor things, and people complain that it would take too long and so
> we won't do it.
>
> Obviously the customers aren't going to be too impressed if we spent 2
> years restructuring the codebase with no user-visible change in
> functionality. But that doesn't mean that *all* refactoring should be
> put off...

Remember that refactoring is not the same as rewriting. Refactoring - at 
least as I understand it - is a sequence of many small baby steps. 
Ideally, the steps should be small enough that you can formally prove 
that they don't change functionality in any way. Such as moving some 
portion of code into a separate function. Or making a public member 
variable protected and providing getter and setter functions for access. 
Or renaming a function.

Each such step is a separate refactoring action, so it shouldn't be too 
difficult to interweave it with your daily job.

Make it a habit to always be a bit more invasive than necessary whenever 
you need to make a change, so that further modifications in that same 
portion of code will be easier.

Make it a habit to set aside, say, two days per month for refactoring work.

Explain to your boss why you're doing this, in terms he can understand: 
You're investing time to improve overall code quality, in order to save 
more time in the future.

Also tell your boss that this is the kind of smart thinking he hired you 
for.

And to stay on good terms with your colleagues, make it clear to them, 
your boss, and also to yourself, that it is your /personal/ desire to 
improve the overall code quality, and that it's ok for you if your 
colleagues don't join in the effort.

Post a reply to this message