South Florida’s Xamarin User Group: Composing an App via User Stories

Intro

I recently gave a presentation last night on constructing an application out of user story modules. I presented my thesis to an audience of mobile developers. They found the idea to be interesting but ultimately impractical. They argued that a solution could be spread so thin with granular projects that it would be overwhelming for developers to maintain the solution as it grows. I agreed with them. However, as solutions grow even without the design that I presented, they are still prone to the same concerns. The design that I presented, results in better maintainability per project.

Code Map

I informed the audience about Visual Studio’s Code Map tool and how it complements user story composed solutions. Code Maps provide visual feedback on a user story’s dependencies. Hence, using Code Map will inform reviewers of a code base on what areas of the code base a specific user story is referencing. I have found that when I use Code Map to review my code, some user stories were referencing DLLs that they shouldn’t have been. As a result, I was able to resolve that dependency which ultimately prevented unnecessary technical debt.

The following image reflects a user story module reflected by Code Map:

Single Responsibility Principle

Keep code together that tends to change together and pull code apart that tends to change for different reasons.

I don’t think this principle is limited to just methods and classes. I think it applies to all libraries. Most of us will acknowledge that a library as a utility should do one thing and do that one thing well. However, most of us do not have that same attitude regarding our client as a library. We tend to have our client by default as an executable with all views embedded within it. This results in our executable having too many dependencies than it’s really required to have.

Code Analysis

In addition to using Code Map to review code, I also run code analysis to quickly identify modules of interests that I may need to audit. Specifically, I rely on the maintainability index of a project to decide if it requires further examination.

The following image reflects the code analysis ran on my solution:

Conclusion

In conclusion, I recently gave a presentation last night on constructing an application out of user story modules. I presented my thesis to an audience of mobile developers. They found the idea to be interesting but ultimately impractical. They argued that a solution could be spread so thin with granular projects that it would be overwhelming for developers to maintain the solution as it grows. I agreed with them. However, as solutions grow even without the design that I presented, they are still prone to the same concerns. I then identified how using this type of design could result in lower maintenance cost on a per library basis determined by code analysis.