IDEA Team Developement / Code Review

Hello,

Since IDETalk is part of Demetra, i'm think that Code Review is very significant feature and will be nice to have it in Demetra.

For example, there are two developers. The developer, who currently fix Bug #1 - named as Max, and developer who curently fix Bug #2 - call him Mike for example :)

Then Max's fix done, his press Ctrl+K (commit changes), and check 'Send for Review to...', press "...", and choose Mike as person who will check Max's fix. Then Max press Commit.

After Max commit, Mike recieved alert with Code Pointers (regions and files that changed Max). Mike quickly check this and close Alarm with "Ok" or "Problem".

The same way, Mike can send commit changes to Max on review.

"Changesets to Review" can be view by reviewer. For example, everyone can see that Max's IDEA is have N pending reviews, M success reviews and P rejected reviews.

Thanks!

15 comments

Since IDETalk is part of Demetra, i'm think that Code
Review is very significant feature and will be nice
to have it in Demetra.


That's good to hear, I have high hopes for IDETalk. One word (well, three mangled together): SubEthaEdit

For example, there are two developers. The developer,
who currently fix Bug #1 - named as Max, and
developer who curently fix Bug #2 - call him Mike for
example :)


Come on, we're talking about JetBrains. There MUST be someone named Eugene on sample conversations :)

Then Max's fix done, his press Ctrl+K (commit
changes), and check 'Send for Review to...', press
"...", and choose Mike as person who will check Max's
fix. Then Max press Commit.


How about Max not choosing who to review his commit? Let's say he would just commit his changes, and make them available for review.

After Max commit, Mike recieved alert with Code
Pointers (regions and files that changed Max). Mike
quickly check this and close Alarm with "Ok" or
"Problem".


Following up on my previous idea, Mike (from now on known as Eugene) would not receive any alert about Max's commit. He would select "Changesets to Review" or something like that. There might be other people doing the same thing too, so it's important that once Eugene start reviewing Max's commit, other reviewers would be able to see that, somehow.

"Changesets to Review" can be view by reviewer. For
example, everyone can see that Max's IDEA is have N
pending reviews, M success reviews and P rejected
reviews.


Exactly! We're aligned here, except that I would prefer to have an option to make changesets available for review, without specifying the reviewer. User administration here is somewhat important: only users with the "reviewer" role would be able to review changesets.

0

Hi,

That's good to hear, I have high hopes for IDETalk.
One word (well, three mangled together): SubEthaEdit


Very nice indeed, but only for Mac?

Come on, we're talking about JetBrains. There MUST be
someone named Eugene on sample conversations :)


Did you already look on JavaPolis schedule? :)
http://www.javapolis.com/confluence/display/JP05/IDEAinAction

How about Max not choosing who to review his commit?
Let's say he would just commit his changes, and make
them available for review.


No, i think that Max may want, but may not want to share changes for reviewing. Just if you want - then make it available for review by checking checkbox on Commit dialog.

Following up on my previous idea, Mike (from now on
known as Eugene) would not receive any alert about
Max's commit. He would select "Changesets to Review"
or something like that. There might be other people
doing the same thing too, so it's important that once
Eugene start reviewing Max's commit, other reviewers
would be able to see that, somehow.

Exactly! We're aligned here, except that I would
prefer to have an option to make changesets available
for review, without specifying the reviewer. User
administration here is somewhat important: only users
with the "reviewer" role would be able to review
changesets.


Hm... interesting :) Yes, maybe it be usefull, but it requires to have a server?

0

>> SubEthaEdit

Very nice indeed, but only for Mac?


Yes, unfortunately. That's exactly why I was hoping to see something like it for IDEA.

Did you already look on JavaPolis schedule? :)
http://www.javapolis.com/confluence/display/JP05/IDEA+
n+Action


No, I didn't. Now I see why Max and Mike :)

No, i think that Max may want, but may not want to
share changes for reviewing. Just if you want - then
make it available for review by checking checkbox on
Commit dialog.


True, but if he wants to share changes for reviewing, he might not want to (or may not be allowed to) choose who to review it. I'm thinking about a medium-to-large development team, where most of the team is composed of junior developers, but more experienced people review their work. In this situation a junior developer might not have the option to choose whether to make his commits available for review (all commits should be reviewed), and might not choose who to review them.

Hm... interesting :) Yes, maybe it be usefull, but it
requires to have a server?


Probably. Something like TMate comes to my mind -- it could provide an additional user management and code review layer over the underlying VCS.

I've actually used TMate to do exactly what I described above: every day I would log in, use TMate to find out what the babies commited in the previous day, and review their changes. The only downside is that I had to revert or rework any trouble I found; it would be nice if TMate had an option to withold changes to the underlying VCS until they are reviewed.

I tried to work around this particular problem with a double layered CVS: Babies could only commit to the first repository; geezers would review changes in the first layer, and commit them to the second one. It was a hell of a work, thou, and this scheme didn't last more than a couple of weeks.

0

Hello Alexey,

AE> Hm... interesting :) Yes, maybe it be usefull, but it requires to
AE> have a server?
AE>

Yes, and, in fact, I think this should be the main way this functionality
is implemented. As nice as IDEtalk might look, it's kind of useless when
it comes to bigger teams, the chances of having everybody in the same broadcast
domain drop as the team size/mobility increases.

And I see this being more valuable for bigger/distributed teams than for
5 developers sitting in the same room.

BTW, where did you read about IDEtalk being part of Demetra?

Best,
Andrei


0

Hello Marcus,

MB> Following up on my previous idea, Mike (from now on known as Eugene)
MB> would not receive any alert about Max's commit. He would select
MB> "Changesets to Review" or something like that. There might be other
MB> people doing the same thing too, so it's important that once Eugene
MB> start reviewing Max's commit, other reviewers would be able to see
MB> that, somehow.

That's something I was hoping TMate would offer at some point, tying reviews
to cvs/svn transactions. Also, being able to somehow condition them (if the
review is mandatory before commit, for instance) would be huge.

Andrei


0

Hello Alexey,

AE> Hi,
AE>
>> That's good to hear, I have high hopes for IDETalk. One word (well,
>> three mangled together): SubEthaEdit
>>
AE> Very nice indeed, but only for Mac?

Cool things start on a Mac :P

R


0


Stuff to google for includes Project Jupiter (for Eclipse), Project Jazz (also Eclipse) and the Netbeans collaboration project.

One thing I'm very interested in from collaboration integration is a lot simpler than code review, though. A "team activity view" would be very strong. Something where I could see what my team-mates were currently doing, so that I could know whether to bug them or not, and keep from stepping on their toes. It needn't be as detailed as "what file am I working on", although that could be useful. A simple view where I could say "I'm working on project 'foo'" or "I'm doing a recruiting phone screen", and see what my colleagues are doing would make my life much easier.

--Dave Griffith

0

Hello Dave,

DG> simple view where I could say "I'm working on project 'foo'" or "I'm
DG> doing a recruiting phone screen", and see what my colleagues are
DG> doing would make my life much easier.
DG>

Dunno, I would be of the opinion that this is something best left of IM not
IDEA. If it's added then I can see people needing to make sure that both
their IM client and IDEA are both up to date.

R


0

Hi,

This functionality is done already by TMate/Perforce Team Changes. Bug i guess, code review is realy good stuff anyway :)

0

On Tue, 2005-11-01 at 15:03 +0300, Alexey Efimov wrote:

Hello,

Since IDETalk is part of Demetra, i'm think that Code Review is very
significant feature and will be nice to have it in Demetra.

For example, there are two developers. The developer, who currently
fix Bug #1 - named as Max, and developer who curently fix Bug #2 -
call him Mike for example :)

Then Max's fix done, his press Ctrl+K (commit changes), and check
'Send for Review to...', press "...", and choose Mike as person who
will check Max's fix. Then Max press Commit.


Also the context is important. There should be a comment field so that
Max can tell Mike about the purpose, rationale, bug-url or other things
that matter for that commit.

--
Per Thomas

0

Hello Vinay,

VM> Is Demetra 6.0 or 5.5?

Demetra is 6.0. There will be IDEA 5.1, but there will be no IDEA 5.5.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"


0

For my own situation, we wouldn't use this because we have a
mixed IDE environment. Some people use IDEA and some people use
Eclipse. We use Ant scripts to compile and package the product.

But even if everyone used IDEA, we wouldn't use this kind of
Code Review feature because we don't do code reviews except when
making a HotFix or patch or other special circumstances.

We simply do not have enough time for developers to be checking
each others code.

We rather spend more time up front reviewing the requirements
and design documents then spending time at the back end of the
process by reviewing the code. Because when you are reviewing
code, you are at such a lowlevel, that you forget to think about
if the code is meeting the overall requirements.

After coding, the areas we focus on are developer unit testing
and performance testing. Each developer needs to write up how
he tested his module/feature etc. Other developers and QA
review this. This can sometimes point out flaws in the code
just by examining how the developer is testing the new module/
feature. Also, we will use YourKit to do performance analysis (
if appropriate) to find hotspots in the code.

Anyway, for the processes we have, I don't see how IDEA can help.
Regular email or a team bulletin board does just fine.

If you are seriously thinking about putting much effort into
teamware, I think you should survey existing customers to find
out who would use this. My gut feeling is not many people would
use this, at least in a corporate/commerical development environment.

0

Well, I for one would use it. At my company, no one (including the senior architects) is allowed to check in anything non-trivial without someone reviewing it. As the team gets bigger, it gets to be sort of a pain to have someone walk over to your desk. Code pointer would rule. Hell, I'd love if we had speech included so I didn't have to make a separate phone call. though that can wait till IDEA 7.0. ;o)

Some other features (haven't used ide talk, so this may be covered):

subethaedit style collaboration, meaning near real time edits apprearing across all the connected ides, with annotation saying who did what. Though a mode where you can make a set of edits before sending/committing them is nice too.

internet collaboration (not just zeroconf/intranet), for things like remote developers.

auto remote debug, so if the app instance is running on the other ide, clicking a button will automatically setup a remote debug target in my ide for that machine/app. I guess sending a debug pointer?

maybe as a helpful addition, an indicator telling me when the class/file i'm viewing locally isn't in sync with the remote copy. Maybe compare file hashes?

Anyway, that's a random brain dump. I'll add more as I think of them.

--pete

0

Please sign in to leave a comment.