Reading Other Peoples & your own old code

Old code is hard to read.  Even your own.  Its not uncommon 6 months down the track, to experience a bit of “what was I thinking when I wrote that?”.  Its one of the first things drummed into me by senior devs at my old work.  The best way to avoid this is to make your code as easy to understand as possible and I believe to do that you need to keep your code modules small (classes & methods) so that they are easy to test. 

But as I try to work with old code bases with long methods and classes with lots of dependencies that are sometimes difficult to test, and with shrinking deadlines to do anything about them, the messages about good practices fall by the wayside.  Its refreshing to see a blog like this, Beautiful Code: A Sense of Direction, talk about the core tennets of keeping things simple, small cohesive classes and refactorings to reduce LOC in addition to a nice example at the start that I read as even your own sh—, um, crap stinks.

BTW, the article made reference to a site that I had come across previously but hadn’t bookmarked which appears to be a great resource on Design Patterns (and Antipatterns) and UML called