Evolving Design Patterns

I like the idea of cleaning up after yourself as you're coding. I find that I do that more and more, however, I get impatient if I spend most of my time, doing 'cleaning', rather than actual 'cooking'.

There's several tasks that I tend to be doing when I'm coding. Creating, designing, refactoring, debugging, and testing. I probably spend 70% of my time refactoring, debugging, and testing. But this is usually 10% of the fun. Where I find fun is in the creation, but I only get to do that 30% of the time.

Though I feel like refactoring, debugging, and testing (RDT) are necessary for good code, it's like cleaning your room...you have have to develop an OCD pride in having clean code to derive pleasure from it. However, you must always balance it with GETTING STUFF DONE.

It's hard to motivate yourself when nothing's actually being done for too long.

While testing has gotten easier and more automated with unit testing, and dare I say it...fun (to watch it say, you passed!), I feel like there isn't a good handbook yet on evolving design patterns.

Much of the time, I find the design patterns in the GoF book to be overkill. However, you do want to think about the future so you can extend it for flexibility later.

So the language that you're working in should allow the flexibility for you to sketch ideas, and then beef them up with ink later. The problem is, unlike drawing, you don't often know what's the best way to beef things up.

Certain types of solutions to problems have varying degrees of flexibility. For example, if I were to write a lexer/parser, I could just write a big loop line by line with a case statement inside it. But what if there are recursive elements? What about callbacks? There are more flexible architectures of lexers and parsers to handle that. However, no book I've ever seen delves into the topic of how to transform a bare bones lexer/parser into a full fledged lexer/parser.

Therefore, you can take the minimum level of complexity that you need, and be able to refactor it later if you need to.