I saw Patrick Szalapski speak on refactoring at the Twin Cities .NET User Group on Thursday night.

Unlike most of these events, this one was hosted at General Mills, the makers of Cheerios and Planters Peanuts amongst other things. Elsa Vezino works with Patrick at General Mills and, as she is now a co-organizer of this meetup, she pulled the strings to have us meet deep within General Mills. Patrick Szalapski is at left in the photo here, not the main focus. I took two standalone pictures of just Patrick but then settled on using this photo instead which shows off the tower of pizza slices stacked atop each other that the guy eating salad crafted. I thought it merited stealing a picture. I was waiting for those three books to be given away during the raffle at the end or at least to be addressed in the talk itself but that never happened as fate would have it. From left to right they are the Clean Code tome of Uncle Bob, Feathers' treatise, and finally "Adaptive Code: Agile coding and design patterns and SOLID principles" by Gary McLean Hall which I had not heard of before. I didn't go to the Twin Cities .NET user group in January because it just had a variation of this talk which I had already seen, but Patrick pulled the GitHub source code from that talk and refactored it in front of us. Much of what he did just involved following ReSharper suggestions/practices. At the end he got into the D of the SOLID principals by showing us how to refactor the direct reference to an external dependency midstream in code out to an external dependency behind an interface. Someone in the crowd asked about when to refactor and you want to refactor the thing you are working on, not random points in the code. At the same time the refactoring should not be tied to a particular story or be the main matter of a particular story. You should just do it as you go. It should also realistically be impossible unfortunately for an outside tester, not a dev, to test. Something that came up some was the crunching of several lines of code into one and, yes, with this comes a harder space to debug in. I have often times had to break one clever line of code into many to get at what was going wrong with it.