Harvesting Idiomatic Patterns

This weekend I did some work to brush up on design patterns and refactoring.  In particular, I have been looking at Refactoring and Refactoring to Patterns.  Both of these books do a great job of explaining how to refactor code into universally accepted design patterns, but what about the patterns that emerge from the design of your application? 

In Harvesting Idiomatic Patterns, Neal Ford states:

Emergent design implies the ability to find design elements in existing code. You can think about those elements as effective abstractions with a reuse potential.

If you look at a code base with the expectation that you'll find abstractions and patterns, they get easier to see.

https://www.ibm.com/developerworks/java/library/j-eaed9/index.html

To me, these are the real patterns you should be looking for in your refactoring.  Looking at the way that you put together the different pieces of your application usually reveals the patterns that work and those that don't.  One of the goals of refactoring...beyond just renaming and moving methods, is to polish up the flow of your solutions; this is what idiomatic patterns can do.  When you set out coding a big project, you really don't know what the solution is going to look like... the devil is in the details and as your project progresses, the picture gradually becomes clearer.  I think that an essential part of refactoring is seeing these idiomatic patterns that are emerging as solutions to your business problems.  They are not Gang of Four patterns, but the patterns you have found that work to achieve your business goals.  

I have found that once you find these patterns, you have what you need to really advance your code base.  Based on what has emerged so far...are we doing this right?  Can we adjust the way our code is shaped to align more closely to our business goals ??  Can we reuse this solution in other places?  How can we abstract a working idea so it can be used in other areas? Answering these questions yields the idiomatic patterns that can define the best practices for your software development team.  

Sure, its good to know about refactoring constructors into creation methods...but take some time to see the forest for the trees.  Listen to what the current code is telling you.  I bet you will start to see the idiomatic patterns that Neal talks about.

I have found that there is a special benefit that can be gleaned from this process.  Once you have the idiomatic patterns that define your business processes - you have the necessary information to create a Domain Specific Language that can be used to standardize the pattern's implementation via code generation.  Scaffolding for basic solutions can be generated from these DSL's.   At a previous employer, I had suggested this could be a boon to mixed onshore / offshore teams.  Onshore workers could define the DSL's and offshore workers could use DSL scripts to generate starter scaffolds that embody the company best practices and idiomatic patterns.  A big hurdle in onshore/offshore development is the communication of these idiomatic patterns and best practices that have been defined in the parent company; through the use of DSLs - stub solutions can be generated thus accomplishing this first step in knowledge transfer between onshore and offshore teams.