Hey,
We all do the code review in our projects, trying to find the faults or bugs in the code written by other team members. Even many people enjoy this work & these are called reviewers. Traditionally we maintain some excel file having the records of all the issues and their status. Though now-a-days people are using tools like Jira, QC or Bugzilla etc to keep record of all such issues. With no doubt, all these are great tools. But I don't think that if you log any code review issue in these then one has to keep both eclipse & that tool open on the screen to map the issue & will be resolving the issue in eclipse & changing its status in these tools. Don't you think that such activity becomes tiresome in case of daily reviews & issues logging & resolving them by the developers. Though it all depends on your project structure, its working & most importantly, agreement with the client.
I just got the chance to go through Jupiter & believe me, I liked this for the purpose of logging the reviews within the team as I think that it is much simpler than other tools like I mentioned above. I have attached the e-book, just go through it once. It is well explained in the book & if still get any issue, just let me know here, I will check out about what I can do to help.
It is a good one, integrated with eclipse. Reviewer need not to open a separate tool to log the issue & developer needs not to open a separate tool to check for the issue, it will be only eclipse, the known territory of the developer & reviewer.
We all do the code review in our projects, trying to find the faults or bugs in the code written by other team members. Even many people enjoy this work & these are called reviewers. Traditionally we maintain some excel file having the records of all the issues and their status. Though now-a-days people are using tools like Jira, QC or Bugzilla etc to keep record of all such issues. With no doubt, all these are great tools. But I don't think that if you log any code review issue in these then one has to keep both eclipse & that tool open on the screen to map the issue & will be resolving the issue in eclipse & changing its status in these tools. Don't you think that such activity becomes tiresome in case of daily reviews & issues logging & resolving them by the developers. Though it all depends on your project structure, its working & most importantly, agreement with the client.
I just got the chance to go through Jupiter & believe me, I liked this for the purpose of logging the reviews within the team as I think that it is much simpler than other tools like I mentioned above. I have attached the e-book, just go through it once. It is well explained in the book & if still get any issue, just let me know here, I will check out about what I can do to help.
It is a good one, integrated with eclipse. Reviewer need not to open a separate tool to log the issue & developer needs not to open a separate tool to check for the issue, it will be only eclipse, the known territory of the developer & reviewer.
| jupiter_guide.pdf |
