| Chris Skardon's profileChris SkardonBlogLists |  Tools  Help |
|
October, 2007 Build Errors: 399, Unit Test Failures: 187... Time to rethink?Being a software developer is all about writing code right, right?? But what about deleting code? At what point should a developer make the hard (and it is hard) decision to rollback that afternoon's / day's / week's work. Plugging away for a long time is something I would have thought a lot of developers were familiar with, and it's tempting to just keep on going, destroying the developer soul inside you and becoming what is known as a 'cynical developer' - or - 'senior developer'. ;) We've all been in the situation where you implement a new piece of code and it (seemingly) breaks every single piece of code that exists in the company, you do a quick 'build' check, and get only 23 errors, not bad eh? Fix them, get down to the last one - fix that - build, gah! 399 errors?!?! Where the f*ck did they come from? What to do??? Well - what are the options? 1. Continue on the route to success. - The design must be right, you will succeed!!! 2. Rollback / rethink - to hell with it! - It's only been a day so far, why waste more?? Each of the decisions has it's pros and cons, option 1 will likely be a hard slog, but ultimately pleasing to finish. Option 2 might lead to a quicker, nicer implementation. Of course, option 2 might also lead to you having to redo the work - which is why before rolling back it's worth copying the folder with your current changes in to another folder, so you can just go back to it as soon as you like / need. Each decision is based on the current scenario, there will be cases where doing option 1 is right, and where doing option 2 is right, and I think being a good developer is being able to figure out which of the two you should choose. October, 2007 Code smelly??? Well... yes, yes it is...There I was reading an ex-colleagues blog site, and came across a recent article about the downside of Code-Reviews, and why they don't work. But this got me thinking, why does he frown on the code review process? I used it in my last position to great effect. I found it provided a fantastic support role for less experienced developers (like myself) and for the senior developer at the same time. The major benefit to the senior developer has to be getting the code changed. It's very easy to sit there talking to your peer developer essentially bad-mouthing the inexperienced developer's code, particularly if all you do is look at it, swear at it and then don't bother mentioning it to the inexperienced dev (I fear I'm guilty of doing this on many occasions). The code review process allows the senior developer to first ask why code was written a given way, and secondly suggest better (?) ways of achieving the same goals. The benefit here is that the senior developer gets an opportunity to get the code changed, and the junior developer learns and progresses (hopefully). Code reviews can also allow the senior developer to learn from the junior developer. Quite often (in my experience) I had kept much more up to date with new technologies and framework (.NET) internals, meaning I used bits of the framework, or tools, which the senior dev didn't know about. The benefit the junior developer gets from this role-reversal is that the senior dev can reign in the junior, and actually get a product out, rather than constantly in a loop of newer and newer technologies being deployed. Personally, I agree, Code Reviews do have limitations, and in general they're best for reviews of how the code is implemented, (using StringBuilder rather than string concatenation for example). They can make everyone (in the team's) code much more inline with each other, and that can only be a good thing! |
|
|
