Solutions Architecture Blog

December 2007 - Posts

Code Reviews and Maintainability
by Mark Strawmyer 12.26.07

Comments    No Comments

Its continually amazing to me how discipline can go a long way to helping ensure a solution has long term maintainability.  Making sure you set parameters and agreed upon standards at the start of a project and then having the mettle to ensure that regardless of how tirelessly you're having to write code you take the time to stay within the parameters.  More often than not when I'm reviewing a solution I see a lack of standards or consistency and excuses such as "there isn't time for it" is almost always the explanation offered or implied.  Or even more shockingly you find an experienced developer that is coding with discipline, but not caring that others aren't and not sharing their best practices.  Open forum peer reviews and discussion of code is something I am a big proponent of in projects especially early on.  It helps ensure that folks are on the same page in terms of style, practices, and that the solution is getting off to the right start.  This is great for reviewing key and common elements of a solution even if it is only practiced early in the project and then abandoned as the project is more mature in the lifecycle.  The downside though is that it isn't realistic to expect that all code can be reviewed by such a process as there is often way too much code.

Enter tools.  Even if there are no explicit standards being followed, there are code analysis and metric tools that can be a big help to making sure the overall solution is more maintainable and performant.  Code analysis will examine the code and look for situations where items may be less than optimal or could be done another way for better performance, maintainability, security, etc.  Common situations are things such as over use of string concatenation where specially designed and class library provided string building objects would be better or inconsistent use of naming conventions.

Code metric tools will examine things such as the overall number of lines of code, depth of inheritence, and cyclomatic complexity which is the number of branches that can be taken within a specific block of code.  The higher the cyclomatic complexity the harder it will be to unit test the code as there are more conditions to test.

There are a number of tools out from vendors such as IBM (Rational), Compuware (DevPartner), and Microsoft (VSTS).  Microsoft recently released the Developer edition of its Visual Studio Team Suite that now includes code metrics and analysis.  I've been experimenting with it and using it to look at a bunch of different code and I've been pretty happy with it and its ease of use and understanding so far.

I highly recommend that developers and development teams adopt a tool to help automate code reviews and perform code analysis and metrics if you're not already.  Even the most disciplined developer will benefit from having an automated review of their code.  It only takes a couple of minutes based on the tool and size of the code base and the results can give you plenty to think about and decide to take action on or not.  Its a great way to learn additional best practices you may not have been aware of by examining the output of the automated review.  Each developer should be responsible for running such as tool against their code and remediating issues prior to having flagged an item as complete.  Again, it is a decision making process as you won't want to blindly make all changes suggested, but such a process prior to turning in code will go a long way to helping overall maintainability.

Migrating from SharePoint configuration to SharePoint development
by Daan De Brouckere 12.18.07

Comments    No Comments

If your IT organization is one of the many experimenting with a simple SharePoint implementation, you'll agree that the out-of-the-box functionality is quite amazing. You can enable your business users to quickly manage their own content, setup workflows, and collaborate. The part that gets interesting is when you're ready to actually start building applications on top of SharePoint. For example, the publication and approval process for content changes doesn't require you to maintain multiple environments, such as development, test, staging or integration environments. Your users are making changes in production! That kind of behavior is severely frowned upon in traditional application development. How do you introduce simple applications in SharePoint while at the same time ensure your business users continue to enjoy the same level of freedom for managing their content?

It all starts with understanding the difference between what Microsoft calls “Artifact Development” and “Assembly Development”. For those of you who are familiar with Software Development Lifecycle processes, the transition to “Assembly Development” will feel very comfortable. It consists of developing code, packaging it up, and deploying it through various test environments before deploying in production. The “Artifact Development” process will require some behavioral changes on behalf of your users that had the freedom over your content. Instead of making content changes directly in production, you’re now asking them to follow a more rigorous process where they’re packaging up their content changes using SharePoint Designer. To understand more about these how to join these two processes, check out the following article on MSDN: Team-Based Development in Microsoft Office SharePoint Server 2007

Before investing too much time and energy in building out formal processes and environments, determine how much SharePoint development your organization will really be doing. Are you just considering building a few features that extend some common behavior, or is SharePoint going to be your platform for a custom workflow solution? How robust is your current application development methodology, and how can you best leverage the tools and processes you already have?

Once you’ve thought about these questions, you can start building the plan for your own customized SharePoint development process.

Relaunch!
by Mark Strawmyer 12.07.07

Comments

The Solutions Architecture blog is now officially back on track!  This will be my forum to hop up on a soap box about various technology related solutions and the involved architecture.  Architecture is one of those terms that is often used but has a different definition depending upon who you're asking and in what context.  But that is precisely why it is the focus of this blog.  The content will be based upon interactions with Crowe, clients, and partners such as Microsoft as we look to solve business problems with technology.  Some discussions are things that will be ultimately powerful due to simplicity and others elegant and unique.

Some prior content has been migrated, but overall it's a fresh start!