Ian is an Eclipse committer and EclipseSource Distinguished Engineer with a passion for developer productivity.
He leads the J2V8 project and has served on several …
Eclipse developers are in the middle of the ‘End Game’. Half way through the release candidates and getting ready for another major release. All the API is in place, the features are ‘complete’ and we are working through the last of the major bugs.
One thing that changes dramatically during the end-game is that each code change requires a review. As we get closer to the release, the number of eyes that must review the code increases. The theory is that with more eyes on the code, the less likely we are to break something. It also forces us (the committers) to explain our changes and convince others that the change is really needed. Often just explaining your code is enough to make you see the flaws in it. Finally, the reviews give us confidence in our changes.
But for a development team that normally does not perform code reviews (at least it’s not part of the mandated development process) the 2 month end-game really mixes things up.
I’m personally enjoying the code reviews. Of course it gives me more confidence in the code I’ve written (or in some cases I walk away with my tail between my legs), but the reviews are also teaching me a lot. We all have our own way of doing things. I have my own coding style; and looking at how others solve problems (and getting feedback on my solutions) is one of the greatest benefits of working on open source. I view software development as an ongoing learning process, and there is no better way to learn than to critique others and have other critique you.
There are two common methods for reviewing code:
So my questions to you are:
Ian is an Eclipse committer and EclipseSource Distinguished Engineer with a passion for developer productivity.
He leads the J2V8 project and has served on several …