Be good, or be good at it
Introduction
This is the second post in the behind-the-scenes look at what it’s like to build and ship a product as an ALM Ranger. The product is the ALM treasure map.
It should also be noted that these posts are meant more as brain dumps than as actual learning references.
What to do with a drunken sailor (with capacity)
In our last sprint, I got all my work done quickly (no walking the plank here)—but I still had capacity. Since the crew also finished early, I couldn’t steal work items to keep myself busy. So what to do?
- Step one: create some work items for myself.
- Step two: do said work items.
- Step three: ?
- Step four: profit!
Hopefully these changes put us in a better starting position for v2 dev, which really kicks off in the sprint starting today!
What did those work items contain?
To create some work items, I started by swabbing the deck—cleaning up the solution, removing old folders, and refactoring code.
Tiles
Starting with the tiles, I went through our assets, removed unused icons, and renamed the existing ones so the correct tiles load at the right resolutions. This was much easier thanks to the improved manifest designer in Update 1 of Visual Studio 2012. I also found missing resolutions, which I sent to Anisha to create artwork for.
Async
Our DB load method used async but didn’t follow conventions properly—so it was changed to return a Task (I didn’t do this myself, but I’m glad it was fixed) and renamed with the _async suffix.
Category
For some reason, we had an old category.cs file in our view models, so in v1 we renamed it to categoryviewmodel.cs. That bothered me, so I removed the old file, renamed it, and fixed the class name. Hopefully, this makes navigation easier and helps with another task below.
ViewModel Injection
One issue in our MVVM implementation was that views were responsible for loading their own view models. Every view either handled this in its OnNavigate event or in XAML—nothing terrible, but inefficient. For example, switching between full and snapped views forced a view model recreation, which could lead to lost state (think: typing in a text box, switching to snapped mode, and losing input).
The fix was to have the navigation system handle this. Using conventions, it now finds the matching view model for a given view and reuses it if available; otherwise, it creates a new instance. The navigation system injects the view model into the view’s DataContext automatically, cleaning up the code in the process!
This added about sixty lines to the navigation code, but now views and view models are simpler to work with.
Code Analysis
Visual Studio’s Code Analysis is part of our quality gate, so I bumped it to full rules (we usually use recommended) to see what it could catch. It found a lot—mostly unused code and cleanup tasks in AssemblyInfo.cs.
I’ve also enabled Code Analysis (with recommended rules) for VS debug builds. This way, we’re always thinking about quality gates while developing, which should make the final sprint smoother!