[pisa-src] Re: IMPORTANT: Code review scheduled for week 2.11. - 6.11.
- From: René Hummen <rene.hummen@xxxxxxxxxxxxxxxxx>
- To: pisa-src@xxxxxxxxxxxxx
- Date: Mon, 26 Oct 2009 14:33:00 +0100
On Oct 23, 2009, at 2:25 PM, Thomas Jansen wrote:
On Thu, Oct 22, 2009 at 03:14:47PM +0200, René Hummen wrote:
For all the text in the mail, it's a rather vague description of
what's
actually planned.
The idea is to evaluate and improve a couple of things (in no special
order):
- code functionality:
Does the code actually do what it is supposed to do? Are exceptions
handled correctly, if at all (for me this is a major item!)? Is there
any usage of blocking calls that could make the implementation freeze
until a timeout occurs? If so, is there a way to circumvent this? Can
the code handle multi-connection scenarios in all its fragments? You
might come up with several other issues to look at...
- code readability:
Is corresponding functionality scattered around the codebase or do we
currently do all the work in a single function leading to a high
possibility of code duplication? Is the functionality well documented
throughout the whole codebase (doxygen)? Does the code contain
supporting documentation by means of comments (again, I think, this is
a major item as it will help new developers make adaptations to the
code more easily)? Once more, you are welcome to add more items to
this list...
- external documentation:
A lot of information in our wiki does not apply in the very way
described in there any further. So my proposal would be that one:
Let's clean up the wiki - move outdated information in a separate
section, modify existing information to reflect our current
development environment, and add lacking information where necessary.
- task management:
As discussed lately on this very mailing list, assignments were passed
on to the assignee rather informally. This should change ASAP, in
order to allow for a more efficient project management and in order to
allow others to quickly get a brief overview about who is doing what
and who can be expected to be kind of an expert in a certain field, in
case questions arise. However, our track system is not up-to-date, so
this needs to be changed as well.
Therefore and in order to get a better understanding of the
codebase for
the new project members, I am scheduling a code review for the
whole week
from 2.11. - 6.11.
A whole week? Who do you consider "project members" for the code
review?
If that includes the average 10h/week HiWi, then 'a week' is quite a
euphemism. Especially for the HiWis it's difficult to agree on a
time when
everyone has to be present.
Well, this certainly applies to us WiMis as well to our HiWis.
Everybody else is welcome to join in at any time. I know, one week is
rather short in eye of the tasks mentioned above. Still, as Diego
pointed out the other day: "Of course, the code is changing a lot.
There is someone working on this thing each day for at least for a
couple of hours." (Sorry, if I don't recall it to the letter, but
think that's what you meant) My point: I want to get as much done as
possible in the time available and just because it's not a whole lot
of time, that doesn't mean, we shouldn't tackle our issues at all.
So, if you stumbled across some piece of code during your
development that
really made your hair stand on end, this phase will be the right
time to
mention and fix that :-)
There are a bunch of people who never touched the source and those
who only
looked at the specific parts they needed to change. I'd claim that
there is
currently no person in the project that knows *all* of the code.
Hopefully, this will change soon.
The plan is to meet up Monday morning (2.11.2009) at 10:00 to shortly
discuss about issues that need to be resolved and parts of the code
worth inspecting. We then assign tasks and spread up to get the work
done.
So we spend an hour or so to make a todo list. What's planned for
the rest of
the week? Do the tasks refer to fixing the items we put on the list?
There's no reason to compile a list and then not to do nothing about
it, right!?
As for parts of the code that are worth inspecting: IMO pisa{s,c}d
are the
heavy duty binaries that need to be stable and efficient, so they
need the
most attention in combination with libpisa (that both use).
I mark pieces of code that need improvement with /* TODO */
comments, perhaps
others do something similar. Doing a simple grep probably yields
enough work
for a day or two.
That's a good start, I'd say.
So I guess my main question is: What's the purpose of the code
review and how
exactly should it happen? As there are still three weeks left,
perhaps some
preparations should be made, like everyone making a list of things
they want
to discuss?
You already pointed out that it's merely a week from now. So yeah, you
may start thinking about issues to discuss.
Ciao,
René
---
Dipl.-Inform. René Hummen, Ph.D. Student
Distributed Systems Group
RWTH Aachen University, Germany
tel: +49 241 80 20772
web: http://ds.rwth-aachen.de/members/hummen
Other related posts:
