[Codestriker-user] Re: Developing new features for codestriker

[Jason R. <jre...@ya...>]

Hi

--- David Sitsky <si...@us...> wrote:
> Hi Eugene,
> 
> I am CC'ing this to Jason, as he did all the metrics work, and I suspect 
> will have some ideas on the best way we should tackle this.
> 
> It might even be worth discussing this on the mailing list to see if other 
> people have some ideas... Jason?

OK, I can give you my thoughts on this. First, the user view.

1. This needs to be able to be turned off, so that people who are not
collecting this kind of data don't see even a hint of it while they are using
codestriker.
2. The "mode" and "Type" selections need to be configured in the
codestriker.conf. Also, the user visible names of the "mode" and "type" need to
be configurable through the .conf file. Different groups will have different
names for the same information. It all must be configurable...

I suggest something that looks like this.

$extra_comment_states = [
{ name=>'Mode', options=>['missing','wrong', etc, etc ] },
{ name=>'Type', options=>['Logic','data handling', etc, etc ] }
];

The default would be, off:

$extra_comment_states = [];

You will want to be able to change the options often to adapt to process
improvements. You don't want to bake this stuff in.

The new/edit comment window should have combo boxes for each
extra_comment_States elements. David is good with the html layout, so he should
be of some help here.

The topic comments tab will need to get combo boxes for each element in the
extra_comment_state. The states will need to be saved when the users presses
the update button. It is important that the metric data always has a empty or
N/A option. If you always pick a default selection, then people who are in a
rush will just leave it. Just leaving it defaulted to some value versus leaving
it empty will mess up your data collection. You will be unable to know if a
specific selection is selected all of the time because people are being lazy
and skipping the selection or in fact you have a real process problem. Make
sure you default these things to blank, and let people pick something. This way
you data will not be junk.

If you actually plan on doing something with the data you will need to add it
to the metric report area in codestriker. The minimal would be to include the
data in the "download all metric data as a tabbed delimited text file". The
generated file has one row per topic, and one column per piece of information.
Every combination of type, and choice would have to be a column. You would have
a column called Mode-Missing, Mode-Wrong, ... Type-Logic, Type-Data Handling.
If you have extra time you can also put the data into the main page in the
default stats that are reported. 


To implement this you need to do the following.

The configuration var needs to be added to codestriker.conf, and defined
Codestriker.pm. This is easy.

You need to get the data into the db. The schema is setup in checksetup.pl. I
would recommend that you make a new table. Call it commentstatemetric. It
should have the commentstate id, and the metric_name as its primary key (pk),
and it should have value as a normal field. See the topicusermetric as an
example. The metric_name, and value should be VARCHAR, 80.  Making a new table
handles 0-n extra comment metrics. Also, adding a table is less work that
modifying an existing table. We can change the rest of this stuff easily after
the fact, but the db schema is a big pain to change afterwords. So we should
make sure that everybody is on the same page for this item.

Next, will be to get it into the object model. Unfortunately, the comment
object  (in Model\Comment.pm) has not been fully objectified yet. Most of the
functions in this module are factory methods that create hashes with all of the
comment data. Let me digress for second. A first pass through the code will be
confusing until you understand the difference between a comment state, and a
comment data. Comment data is a single comment by a single person. The comment
state is really the "issue/bug/defect/ etc", and the comment data is all of the
comments about the base issue. The Comment module kind of mushes these two
separate things together. The new table that you are going to be adding is for
the "commentstate" (aka the issue), not a specific comment on the base issue
(aka the comment data). The database schema is designed right, so you may want
to take a look at that before looking at the Comment.pm module. The easiest
path through Comment.pm would be to add a new data member called
self->{metric}, that is a reference to a hash. The hash would have a key for
each type of metric, and the value of the key would be the current selection.
The read_all_comments_for_topic function would need to do an extra query
pulling all of the commentstatemetric data out, and stuffing it into the
collection. The Comment.pm will also need to learn how to change the metric
data. You should see the function called change_state to see how to do this.
This function should know how update an existing metric selection, create a new
metric selection, and to delete an existing metric selection if the user picks
a blank selection.

Moving up the next level, the ViewTopicComments.pm, SubmitEditTopicSTate,
SubmitNewComment.pm, and SubmitEditCommentState.pm will need to be changed to
load the current metric data into the template files, and get the metric data
from the params into the comment object. Our policy is to keep the action\*.pm
files as skinny as possible. So if you are doing more than moving data between
the objects and the templates then move the code out into the model area.

Next is the Templates. If you don't know how to use the excellent Template
toolkit, you will need to learn it now. Basically, the template toolkit is
going to want each comment metric in a list of hashes. The hashes will have the
name (aka label), the current selection, and a reference to a list with the
possible pick lists. The outer loop will be the number of comment metrics types
configured

for each metric type
   print label
   print current selection
   for each selection 
      print selection

You can look at the viewtopicinfo.html.tmpl for examples. 

You need to be ready to deal with data coming from the db that is not
configured in the codestriker.conf file. The conf file will change, the data in
the db will not. The Action\* files should merge the current topic selection
into the list of possible topic selections from the config. You can merge two
lists together by sticking them into a hash, with all of the values being 1.
Duplicate's will be eaten by the hashing key mechanism. If you get this far,
you should add a function to Codestriker.pm to do a set_union, so other parts
of the app can use this. We have this code in several places now, and it should
be pulled out.

The Action\*.pm files don't actually touch the cgi query object. You will need
to modify the http\Input.pm to extract the params from the html form, bless
them for taint checking, then copy them into the input hash. This object is
needed to help insure that all parameters are clean and don't have any bad
stuff in them to mess up the computer that codestriker is running on.

The metric reporting will require changes to the MetricStats.pm file. The
get_download_headers, and get_raw_metric_data will need to learn about the
comment state metrics. The only comment to make about this is that the headers
should be driven from the db, not the conf file. Again, if the conf file
changes you will still want all of the older metric data to be present. This
should be some easy SQL to do this.

Thanks
Jason.

> 
> Cheers,
> David
> 
> On Wed, 16 Jun 2004 04:51, Robin, Eugene wrote:
> > Hi, my current employer wishes to use Codestriker for our code review
> > process. My job will be to add several features to help users better
> > classify problems that they find (also, it will help our company's
> > metrics collection). My boss wants to have three drop down boxes during
> > the process of commenting on a line of code. So, he would like something
> > like the following show up along with the comment section:
> >
> > Level                 Mode                Type
> >
> >     Major                Missing             Logic
> >
> >
> >     Minor                Wrong               Data Handling
> >
> >                             Unclear             Interface
> >
> >
> >                             Suggestion        Error Handling
> >
> >                                                     Performance
> >
> >
> >                                                     Comments
> >
> >
> >                                                     Standards
> >
> >
> >
> > What I'm interested in, is where you recommend I start in getting this
> > feature into Codestriker? Any help would be greatly appreciated as I am
> > quite over loaded with other tasks as it is.
> >
> >
> >
> > Thank you.
> >
> >
> >
> > Eugene
> 
> -- 
> Cheers,
> David
> 
> 


		
__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail