Training Materials...
So after realizing that the 10,000 page book on ASP.NET is better as a reference than as a training guide (seems like someone said that several times before we started this book), we voted on whether to read Clean Code or Refactoring to Patterns next. Considering the make up of our team and the state of our code, I lobbied fairly hard to get Clean Code in front of everyone before we dive into patterns (again).
It seems that a lot of our more experienced developers are pretty resistant to reading Clean Code. I think there is a mentality that "the way I do it is right and there is no need to change or improve." I think that is pretty sad. I read Clean Code a few months ago, and it has helped me vastly. It is amazing how much more maintainable my code is now.
Anyway, I think that for my team (we have not quite a 3 to 1 ratio of juniors to seniors) we need to have a purpose to our refactoring. Making our code more readable and reducing our coupling seems like a pretty worthy purpose. I shudder at the thought of a couple of juniors pairing together and going pattern crazy on some code block that should be simple and straight forward. Don't get me wrong, I think that design patterns are a great idea. I look forward to reading Refactoring to Patterns when it comes up in my personal queue. I just prefer that our mentoring/training take a more methodical approach.
When I finally convinced my team to start using MVP, I had juniors come up to me and tell me that "this new pattern doesn't make my code any more testable at all!" When I looked at the implementations, they had usually done a Supervising Controller and but all of the business logic in the view. Go figure. When you implement the wrong pattern, or misunderstand the pattern, you don't see any of the benefits of the pattern. It seems likely to me that reading a patterns book is going to take us right down that path again.
Ah well, democracy worked and the correct book was selected.
It seems that a lot of our more experienced developers are pretty resistant to reading Clean Code. I think there is a mentality that "the way I do it is right and there is no need to change or improve." I think that is pretty sad. I read Clean Code a few months ago, and it has helped me vastly. It is amazing how much more maintainable my code is now.
Anyway, I think that for my team (we have not quite a 3 to 1 ratio of juniors to seniors) we need to have a purpose to our refactoring. Making our code more readable and reducing our coupling seems like a pretty worthy purpose. I shudder at the thought of a couple of juniors pairing together and going pattern crazy on some code block that should be simple and straight forward. Don't get me wrong, I think that design patterns are a great idea. I look forward to reading Refactoring to Patterns when it comes up in my personal queue. I just prefer that our mentoring/training take a more methodical approach.
When I finally convinced my team to start using MVP, I had juniors come up to me and tell me that "this new pattern doesn't make my code any more testable at all!" When I looked at the implementations, they had usually done a Supervising Controller and but all of the business logic in the view. Go figure. When you implement the wrong pattern, or misunderstand the pattern, you don't see any of the benefits of the pattern. It seems likely to me that reading a patterns book is going to take us right down that path again.
Ah well, democracy worked and the correct book was selected.
Comments
Post a Comment