Most of what we did this week was look at Refactoring. When I was buying the book on Amazon, a lot of the reviews said that this is one of those "if you're working as a Software Engineer, you should read this" books. I do like the kind of "peace of mind" that refactoring gives you that you can always fix things later if you discover a better way (which in most cases you will) and you shouldn't have to feel bad about it. You don't have to sit there and think of all the future possibilities instead of sitting down and getting code written. But it isn't okay to not think of the future at all.
For the reading "New Methodologies", I really like the way that the author describes agile. Being flexible and open to change appeals to me. During one of my internships, the team I was on was making the transition to SCRUM and I think there was a complete failure in communication about the benefits of the new system. He mentions several times that if you don't have people that are willing to do the work associated with an agile methodology, things just won't be right. The software where the team had to fill out estimated times and priorities for tasks in each sprint just seemed like more bureaucratic busywork than something to help the software engineers. I didn't stay long enough for it to actually be implemented, but I have no doubt that it had less impact than on a team who understood the benefits completely. It also made me think less of the extra work these methodologies bring to the table.
Looking forward at what's scheduled, I see that we're taking it one step further with the example of the first chapter, which seems cool and gives more meaning to covering all the other refactorings in class.
No comments:
Post a Comment