Team Code Review & Design Sessions
XP is about getting the right values and practices and maximize it to the extreme. CODE it's essential and practices like pair programming and unit testing / test driven are a must have. I don't think they are enough, so i like to work a lot with team code reviews and design sessions.
As a Software Architect I found such techniques very effective specially in scenarios that the team is beginning with XP and don't do pair programming effective or the team technical skills have a huge contrast. I'm not against pair programming of testing BUT this old fashion techniques work as well.
Performing a Code Review
I don't use any especial tool for code review. I do code review in two flavors , first in the automate way, using tools for code analysis like PMD, Checkstyle, FindBugs and Sonar. Use can do manual check using eclipse plugin for example or integrate that tools using ant or maven in your continuous integration system.
Even using all this tools I still do manual regular code review sessions because somethings you just get if you take a look in the code your-self. I do it in a very simple way, I just create a simple plain text file and then make a list with the things that I see. Sometimes I do some optimizations like put TODO notes on the code this proof very useful because developers can easy track what change and where just looking their todo view on eclipse.
After a code review(I always do it alone) I do a meeting with the team to show what are the thing that I get and how they can improve it and do it better on the next time, this is not just communication but providing people explanation avoid that some mistakes or issues appear again. Talk with people about the code improvements is good not because their learn how to code better but also because somethings you discover nice stuff like this code will die next sprint or the story will change a lot and this will be different and all this information leads to communication with the team, in the end of the day the team is in the better position to make the call and decide what change or not.
Sometimes code reviews are source of technical debts, I just show to the team what I get and them let the team decide if is a big deal, will be fixed now or its a technical debt and should be on the wall and should be managed. Ultimately code review sessions are great opportunities to promote the right culture and endorse values like Openness, collective ownership, courage and also simplicity.
I always like doing that sessions because every time at look the code I found less and less issues, the standard is something live and in the developers veins. Developers have a great change to learn how to improve their code efficiency and new technical tips and classes, frameworks, libraries, techniques, etc, all happen in this code review sessions.
Design Sessions
Software architecture it's about communication. Design sessions is one of the tools more effective to me as a Software architect to communicate the design style and code standards that I consider right for the project. The true is that lots of architects sucks, because their are living in the ivory tower throwing jars and presentations full with bullshit to the team.
This is disturbing. I found much more effective work really close to the team, software architect is not only about getting the big rocks and the nom-functional aspects but also how the system can evolve or not, not being present with the team is nasty and totally wrong.
I like use XP practices like the roads approach and simplicity in that sessions. What a great opportunity to talk and make the team understand design and architectural concerns then using a white board a talking with they about my point of view.
Other thing that I always do is let the people work on "architectural" tasks because don't thing that I'm the only guys who should work on the "architecture" BUT I just do that when people are ready and have the skills to perform that task, the opposite will lead to pain and exposure people.
Design Sessions are cool not only because of the technical perspective but also because we'are talking about business and business requirements and this create very valuable conversations and provide context do get the right solutions.
Cheers,
Diego Pacheco
As a Software Architect I found such techniques very effective specially in scenarios that the team is beginning with XP and don't do pair programming effective or the team technical skills have a huge contrast. I'm not against pair programming of testing BUT this old fashion techniques work as well.
Performing a Code Review
I don't use any especial tool for code review. I do code review in two flavors , first in the automate way, using tools for code analysis like PMD, Checkstyle, FindBugs and Sonar. Use can do manual check using eclipse plugin for example or integrate that tools using ant or maven in your continuous integration system.
Even using all this tools I still do manual regular code review sessions because somethings you just get if you take a look in the code your-self. I do it in a very simple way, I just create a simple plain text file and then make a list with the things that I see. Sometimes I do some optimizations like put TODO notes on the code this proof very useful because developers can easy track what change and where just looking their todo view on eclipse.
After a code review(I always do it alone) I do a meeting with the team to show what are the thing that I get and how they can improve it and do it better on the next time, this is not just communication but providing people explanation avoid that some mistakes or issues appear again. Talk with people about the code improvements is good not because their learn how to code better but also because somethings you discover nice stuff like this code will die next sprint or the story will change a lot and this will be different and all this information leads to communication with the team, in the end of the day the team is in the better position to make the call and decide what change or not.
Sometimes code reviews are source of technical debts, I just show to the team what I get and them let the team decide if is a big deal, will be fixed now or its a technical debt and should be on the wall and should be managed. Ultimately code review sessions are great opportunities to promote the right culture and endorse values like Openness, collective ownership, courage and also simplicity.
I always like doing that sessions because every time at look the code I found less and less issues, the standard is something live and in the developers veins. Developers have a great change to learn how to improve their code efficiency and new technical tips and classes, frameworks, libraries, techniques, etc, all happen in this code review sessions.
Design Sessions
Software architecture it's about communication. Design sessions is one of the tools more effective to me as a Software architect to communicate the design style and code standards that I consider right for the project. The true is that lots of architects sucks, because their are living in the ivory tower throwing jars and presentations full with bullshit to the team.
This is disturbing. I found much more effective work really close to the team, software architect is not only about getting the big rocks and the nom-functional aspects but also how the system can evolve or not, not being present with the team is nasty and totally wrong.
I like use XP practices like the roads approach and simplicity in that sessions. What a great opportunity to talk and make the team understand design and architectural concerns then using a white board a talking with they about my point of view.
Other thing that I always do is let the people work on "architectural" tasks because don't thing that I'm the only guys who should work on the "architecture" BUT I just do that when people are ready and have the skills to perform that task, the opposite will lead to pain and exposure people.
Design Sessions are cool not only because of the technical perspective but also because we'are talking about business and business requirements and this create very valuable conversations and provide context do get the right solutions.
Cheers,
Diego Pacheco
