Find a method that's more complex than average. Use "extract method" refactoring to decompose a complex method into smaller pieces: private methods with self-documenting (doesn't-need-comments) names and correspondingly well-defined roles, like createNewThis, storeThat, and processIntoTheOther. Then convert each of the private methods into an interface/implementation pair. Apply this across a project, and you find yourself with pyramids of objects. The very lowest-level business and integration operations are encapsulated by small building blocks at the bottom. Mid-level objects are no larger than the lower, but assemble the lower-level objects into useful sequences for doing work. Higher level objects continue extending this pattern of maintaining small size but assembling functionality from lower-level chunks. Then unit testing any single object is as simple as mocking the few objects it depends on and testing that it invokes its dependencies in the right order and passes them the right parameters under whatever conditions it's in charge of knowing about. Changing behavior is equally easy because simply writing a new implementation of an object that's <100 lines is nothing. The old implementation stays around for reference, including its supporting tests, or it and its tests can be removed. No more changing the code and then having to trace through old tests to see what needs to be fixed there. Polymorphic open/closed.
I've fiddled with my blog template because I decided I wanted more horizontal viewing space, given that it was using less than a third of my 1920 horizontal pixels. If it feels too spread out for you, I added a drag-and-drop handle over to the left to let you resize the main content column. The javascript is pretty primitive. If it breaks, drop me a comment.
>
>
>
>
>
>
>
No comments:
Post a Comment