September 2005 - Posts
FxCop output has a problem: a high signal:noise ratio. (Do I mean high or low?)
I mean that there seems to be a lot of noise in the output for a few good bit of information.
In Visual Studio 2005, the Code Analysis warnings/errors turn up in the Error/Warning/Info window, and the nice thing is that they can navigate directly to the code that caused the entry.
I think there are a couple of ways that Code Analysis could be more useful. The output should be more structured, for one thing: group and sort it on the category and rule, rather than listed by source code line. So you could drill down on the category and rule, and see all the code lines that broke that rule - you could decide which rules to fix, which to ignore (rt-click ->Ignore and it either marks the code with the attribute or it changes the Code Analysis warning level for that rule). Rules should have a severity rating too, so its more than just Off, Warning, and Error. You could prioritize the work activities easier with a severity or risk rating for each rule.
And, there should be Intellisense fixes linked to the rules, so that you could ask the editor to fix it. Hover over the code that breaks the rule, and you get the "what can I do to fix this?" popup.
As it is, I have regularly ignored FxCop output in past projects because it is so exhaustive. I'm not proud of that, but I would like to use my review time more productively than fixing these warnings.
I am teaching Visual Studio Team System in France this week, and during the discussion that compares some of the different SDLC's that are in use, such as Waterfall, Unified Process, Scrum, Extreme Programming, V-model, MSF, and so on, one of my students made a point about Extreme Programming: because the developers work in pairs in XP, there exists a natural mechanism for training and mentoring.
I don't see the same opportunities inherent in the other processes.
And during Joel's webcast last night, he asked the question, "do you use the same process for every project?" It has been our experience that many companies do choose an SDLC and then use it exclusively. Simply because until Team System, enforcing the process on the team means a tremendous commitment in time and energy, and often persuasion (with a pointed stick) from a project manager. Now, with VSTS, the process template defines the process, and the tools help to enforce them. So it should be easier to pick and choose which process for each project. Or make a process using elements of other processes.
Of course, that would mean you would need a good editing tool for VSTS process templates - something that helps you create new processes using elements from others. Hmmm, stay tuned folks, we're working on that very tool. You'll probably hear Joel talk about process templates in his next webcast.
Anyway, next time I run into a project that has an element of mentoring necessary in the team (ie. some senior devs, some junior devs), I will think about how I could use elements of Extreme Programming in the process.
I've been using the Dataset designer this week for a project we are building in ASP.NET using VS 2005.
If there's a way for me to turn off the automatic creation of a DataAdapter for each table I drag out onto the designer surface, someone please tell me now!
Really, I suppose for quick-n-dirty developing, having it automagically created could be useful. But I have both philisophical and user experience reasons for not liking it at all.
Philisophically, this just doesn't fit in with the way I fill datasets. I have a data access service (either a web service or an assembly) that takes a typed dataset and a set of criteria and fills the dataset with one call. I have a stored procedure generator that creates stored procedures that the service calls - the Select sprocs (SelectAll, SelectPK, SelectFilter) understand the "main" table in each dataset and apply the criteria to those, and return a multiple resultsets to the service, which fills each table in the dataset. So one call does the whole dataset, not one call per table. When persisting changes, the service takes the dataset, extracts the changes, and iterates through the tables, creating its own DataAdapters and doing the Insert, Update, and Delete methods. So, again, from the point of view of the consumer of the data service, one call does it all again.
From a user experience, I am dropping a table onto the designer, then I try to select the DataAdapter portion that is below the table definition - if I don't get just that adapter selected and press Delete, the whole table and its adapter is gone. If I do get the adapter selected, when I hit Delete, I get a "mother-may-I" question - "This will delete the data adapter. Do you want to delete the table as well?" Now, when you hit Delete in pretty much any other program or function, normally the prompt message box is phrased so that "Yes" means "Yes mother, I want to delete this [thing]." So while I am already annoyed at being forced to delete something I didn;t want in the first place, half the time I answer Yes to the Delete question, and end up deleting both the adapter and the table itself. Fortunately, the Undo brings back (both) the table and the adapter. So I find between the difficulty in selecting the adapter only and the oddly-phrased question, I am about 50% productive in the DataSet designer. (for the record, I don't think the "mother-may-I" question is necessary in this case at all).
Along the same lines, I have been finding the ObjectDataSource ASP.NET control somewhat useful with the controller classes I have been making for the business logic. With a little adjustment, I have been able to use it for the Select operations and binding to databound controls. However, I have been finding it tough to use the updating methods on the datasources, because they assume again, that we are updating a single table at a time. I would like the DataSource objects to fetch a dataset and "host" it within the container, allow access to the data from various controls (different grids or tabs are bound to different tables), and then make a single call to persist all the changes at once. It seems to me that the databound controls that allow editing, inserting, deleting, etc, all want to force the persistence call on the datasource, rather than simply doing their work of collecting the changes and notifying the datasource that the data has changed. Perhaps another UI control could then notify the datasource that the user requested the changes to be persisted (or abandoned). In other words, I want each of the editing controls to allow for changes without forcing the persist to occur immediately.
Maybe there's a method I can overload or an event I can catch to get this behaviour to work the way I want it to. But I haven't looked for that yet.
Mike
Joel was on DotNetRocks, talking about Visual Studio Team System.
Fundamentally, it was a great interview.
More Posts