When building out SharePoint systems more often than not some element of custom code will be involved. This is especially true if the requirements are challenging or don’t quite stick to traditional ‘out of the box’ SharePoint behavior. In SharePoint 2013 this could mean the use of JavaScript, C#, VB.Net, even PHP or Ruby to build customizations.

The quality of these customizations, and the code used to build them, can have a huge influence on different aspects of the SharePoint platform:

• Security: Poorly written code can introduce security flaws that are hard to detect.
• Performance: ‘Better code equals better performance’ is so often true. Bad code can have a big impact on the speed of the final application.
• Maintainability: ‘Spaghetti code’ might get the job done and fulfill the requirements for now, but makes it really hard to apply changes in the future.
• Stability: Badly written code can have hard-to-find bugs, which decreases stability and can result in more errors.

In the past SharePoint code could only be deployed as a ‘full trust farm solution’. Microsoft Premier Support, the helpdesk for SharePoint professionals, received more calls caused by badly written code in farm solutions than almost anything else. Microsoft needed a better approach. After the first rather unsuccessful halfhearted fix called “Sandboxed Solutions”, they introduced the ‘App development model’ in the latest version of SharePoint. With Apps, their code is not run on SharePoint servers, and thus a lot of problems listed above simply can’t occur (plenty of others arise, but this is a different story).

The ‘App model’ permits only client-side code (e.g. JavaScript) or server code running on an entirely separate platform away from SharePoint. For example, a SharePoint App can be written in PHP and hosted on a separate Linux server, but then be called from and exchanged data with the SharePoint platform.

In any development scenario, even those still using full trust solutions, good development practices are hugely important. This blog post will outline several strategies that can increase the quality of code in your SharePoint applications.

1. Choose the right SharePoint development pattern

Full trust solutions

Full trust farm solutions are very well alive and certainly will be around for many many more years. Microsoft has committed itself to deliver SharePoint on-premises releases in the future and for some organizations, this might the only viable option.
This development pattern we are using now has been well established since SharePoint 2007 and is the most flexible and powerful way to customize SharePoint. But with great power comes great responsibility. Too many things can go wrong in a full trust world as described in my article “Five reasons to avoid ‘Full Trust’ solutions in SharePoint”.

Nowadays, I avoid them as much as possible and try to find a solution for the business problem with an app, or at least with minimal usage of server-side code. By this, you can assure that future upgrades of SharePoint or a migration to the cloud will have minimal impact on your code.

Sandboxed solutions

Sandboxed solutions were the first attempt by Microsoft to address the downsides of full trust code. They run in a secure, monitored process that has access to a limited part of your SharePoint farm. Naturally, this means also limitations to what you can do with them. Read more about that in the “Sandboxed Solution Considerations” on MSDN. With SharePoint 2013 and the dawn of the app model, Microsoft deprecated the use of managed code in sandboxed solutions meaning that you should only use them to deploy declarative code like content types, fields, list definitions, etc.

It is pretty clear that Microsoft will not invest anymore in sandboxed solutions, so rather avoid them if possible.

Apps

SharePoint Apps come in two forms: ‘SharePoint hosted’ and ‘provider hosted’. Provider-hosted apps are usually more complicated, due to the fact that an external system is involved, but offer a wide range of hosting and coding options. SharePoint hosted Apps are rather straightforward forward but only JavaScript can be used to write customizations.

It is really important to choose the right pattern up front because it is harder to change when development has already started. Microsoft has published an excellent article that should help make this decision easier.

2. Design patterns and methodologies

A wide range of design patterns has been developed and documented over the years. They offer a great insight to the fundamentals of writing quality code. By following a design pattern, code should be more maintainable and readable. The Model View ViewModel is a classic and excellent example, one where logic code is separated from that needed for the user interface.

Dependency Injection and Inversion of Control are also popular patterns and techniques to build loosely coupled systems where components can easily be replaced.

Looking into the brave new SharePoint app world models like ASP.net MVC (Model View Controller) and Angular.js MVW (Model View Whatever = MVV or MVC) seem to have become widely accepted. Still many development scenarios and patterns on top of that, which we got used to not working anymore, or work differently. Hence, Microsoft and several volunteers of the SharePoint community are providing an Open Source project collecting and refining Patterns & Practises to solve these common problems. I would recommend anyone developing apps to check out their code on GitHub to see if there is already a solution for your problem available that can be re-used.

In general, the choice of a model mostly depends on the experience of the developers building the application, but the key thing to remember is that a proper software design will result in better code.

Use a model where one exists and makes sense, but not just for the sake of it. Wise words, I know 😉

3. Implement regular code reviews

Developers make mistakes. And everyone struggles when reviewing their own work. So independent code reviews should be held regularly and made part of the development schedule. They will help to detect and mitigate mistakes and can be as simple as asking the developer in your team to look over things.

Code reviews can be performed in many different ways eg. Over-the-shoulder, pair programming, tool-assisted, etc. but, because of the human involvement, they all have in common that they will help you to improve the quality not only from a technical but also from a functional point of view. This is something no automatic code review can compete with as it just does would not understand the purpose of the piece of software (unless you teach it to explicitly).

As a side effect, code reviews help the team to learn from each other building up a common skillset and eventually a more uniform and easier maintainable code.

4. Analyze your code for quality

During development, it is a good idea to use a dedicated tool to analyze code. For example, our own SPCAF will analyze the code against 600 quality rules and generate a report detailing its findings. Fixing the issues highlighted will increase performance, maintainability, and stability and save you lots of time and trouble already before your code is deployed to the production environment.

One thing you have to be aware though is that whichever tool you are using will never be the silver bullet. A tool can only check against rules that exist and there are always plenty of additional practices and errors that could be validated. Also, especially in SharePoint development, many coding practices depend very much on your target platform and your own practices and corporate guidelines.

Let’s just think about the everlasting fight between the declarative and programmatic approaches in full trust farm solutions. Declaring for example content types in XML was long considered to be the better (though harder to debug) way compared to using a feature receiver and coding the content type in C#. Both approaches have their advantages and a tool can recommend and validate either one, but in the end, you have to define which is the better one for you.

Hence tools like SPCAF provide configurable rulesets allowing you to adjust the analysis to your requirements, as well as a Software Development Kit (SDK) to implement your own rules checking your specific patterns and practices.

When you have done that, the tool can help you to make sure you remain consistent throughout your solution or projects.

Making good code even better

One problem with writing quality code is that it is difficult for an outsider to detect the quality between ‘good’ and ‘bad’ code. Bad code might fulfill the requirements, it might do the job at hand, but it could create issues in the future. Bugs could have been being introduced that can affect the performance, and they might not be apparent right away.

At the same time, ‘good’ code can generally always be improved. It can be made more performant, can be streamlined, or take advantage of new techniques and approaches. The SharePoint App model is a good example. Lots of full trust farm solutions contain excellent code, written in a professional way, but the App model is still a better future-proof approach.

Either way, it is always a good idea to put more effort into the design, analysis, and review of code upfront. This way the quality of the code will improve, and so too will the quality of the solution – which is ultimately what everyone wants.

Merken