by David Mann, Aptillon / Critical Path Training
SharePoint development is hard, right? We’ve all heard that time and time again to explain why implementations take longer and have problems.
But guess what--it’s a lie. SharePoint development is no harder than any other ASP.Net development, and in some cases, it’s easier.
What’s hard is SharePoint itself. SharePoint is a huge product with lots of moving parts. Knowing all of them is hard (it takes a Master) and knowing which parts to make use of to solve a business problem can get tricky.
But none of that is development; that’s all design and architecture. The process of actually writing the code is easy—especially now that the tools in Visual Studio 2010 abstract so much away from us and do so much for us.
Maybe this is splitting hairs, but I think the distinction is important. It means that people designing and architecting SharePoint implementations need to ensure that they get the hard parts right and then the developers need to deliver on that design with a well built, professionally developed codebase.
If either side of this falls down, then the implementation will fail.
What does this mean for us as developers? Keeping the distinction in place between design/architecture and development, it means that we need to get better at our craft or else the need for our services is going to be significantly reduced.
Let’s face it; SharePoint Designer is a much more capable, viable product in the 2010 release. It enables non- or less-technical users to do much more than ever before.
SPD, combined with the JavaScript Client Object Model and the rise of JavaScript libraries like JQuery, is making it easier for users to add the functionality they need directly to the site.
The need for custom server-side code is diminishing. If we can’t get the coding side of the equation right, the architects will start designing solutions that don’t rely on developers quite so much.
Server-side code won’t ever completely disappear, but it is waning, and if we don’t get our act together we are only adding more nails to our own coffins.
So, what do we do? In a nutshell, we need to put our “real developer“ hats back on.
Those of us that have been in this field for a while probably did “regular” ASP.Net development in the past. Those of us that are new to the field (i.e., started our careers as SharePoint developers), may not have ever done anything else. In either case, we often don’t consider ourselves as ASP.Net developers, but guess what? We are.
Often this disconnect was because the tools and processes that other ASP.Net developers could use were not available to us in the SharePoint world so we largely ignored them. We can no longer afford to do so.
I’m painting with very broad brush strokes here, so not all of this will apply to any one person or team, but here are some ideas on where to get started, in no particular order:
1. Throw exceptions: just do it. Use the standard exceptions defined by .Net or build custom ones. It doesn’t matter. Returned error codes and empty catch blocks have no place in professional code of any type.
SharePoint will catch your thrown error if something higher up the call stack doesn’t handle it and present a more user-friendly message to your end users. This is a tried-and-true approach to writing professional code and we can’t ignore it. Here’s a good place to start, with this Microsoft MSDN article.
2. Code reviews: you need to check your ego at the door. Have another developer review your code – through either a formal process or just asking someone to take a quick look when they have a minute. We all write good code and we all write not-so-good code for a variety of legitimate reasons (lack of time, evolving requirements, ignorance, etc.)
None of these are a problem if we are willing to submit our code for review by another developer. Two sets of eyes are better than one and outside input on our code is the easiest way to learn and get better. Along the way, everybody learns something new – either by reading someone else’s code or by having someone else read their code, ask questions and make suggestions.
3. Patterns: Why are we reinventing the wheel every time we start a project? There’s likely a known-good pattern that can be applied to just about any situation we will face in SharePoint and that will help us to ensure that the code we are writing is secure, robust, efficient, etc. The Patterns and Practices group at Microsoft has published guidance that includes some sample patterns that just make sense for use in SharePoint projects. If you’re not familiar with this guidance, you need to stop writing code until you have at least perused the following this Microsoft website. There’s a lot there so you won’t become an expert in it overnight, but you need to start that journey now.
4. Load Testing: Well worth it. How can you possibly expect to know how your custom code will perform in real production situations if you don’t test it under simulated load?
5. Automated Unit Testing: A good thing. Seriously. Say what you will about how doing this in SharePoint doesn’t work because of all the internal constructors and sealed classes, but this boat has sailed already. The larger development community has spoken and automated unit tests are a good thing.
You don’t have to be a zealot and have 100 percent coverage but you should use unit tests where it makes sense for any non-trivial project. Without unit tests, refactoring your code is an exercise fraught with peril that takes longer than it should.
6. Refactoring: Also worth the time. Speaking of refactoring, it is an excellent practice in and of itself. No one, and I mean NO ONE, gets the code dead-on right the first time through (unless the work is so trivial that there’s almost nothing there to refactor anyway).
Refactoring doesn’t mean you are a bad developer; quite the opposite. It means you are a well above average developer. Write the code first to make it work and to prove out the paths through the process and then refactor to clean it up, avoid problems and make it bulletproof and maintainable.
7. Instrumentation: More than logging errors. Although SharePoint provides us with the ULS logs it is not sufficient to only write the occasional error entry there. For one thing, the IT department often doesn’t monitor the ULS logs, so little problems that could be caught and dealt with early will go unnoticed until they become a Big Deal.
In any event, Instrumentation is more than simply logging error messages. Instrumentation means that you are recording information about the processing of your code, even when everything is working perfectly.
This helps to ensure that when things do go awry, it can be noticed sooner and dealt with more easily.
Instrumentation can also be used during development to help debug. Here are some of the things to consider for adding instrumentations to your code:
a. Writing to the Windows Event Log: most IT departments monitor the Event Logs on their servers so anything written here is likely to get noticed. Don’t write too much here, though, as it then makes it harder to separate the signal (real problems) from the noise (extra chatter about your application’s processing)
b. The Developer Dashboard: In 2010, SharePoint includes the Developer Dashboard that can be used to provide details about a given request. This can be extended to include your own information. See this MSDN piece for more information.
c. Writing to the ULS logs: while this is not sufficient by itself, it is an important part of instrumenting your application. Feel free to be as verbose as you would like here, within reason, of course…
d. ASP.Net Tracing: Whether you are using the Developer Dashboard or not, adding tracing information to your application can help debug a process. See this MSDN piece for details.
e. Conditional Compilation and the Conditional Attribute: Use these .Net capabilities to include extra logging in your debug build that will be automatically stripped out when you compile a release build. See here for how-to's.
8. Tools: There are many. The tools available to developers to save us time and improve our code are numerous. Some of them cost money; some of them are free.
Regardless, you should talk to other developers, find out what tools they use and investigate them. If they will provide you with value, consider buying them or getting your company to buy them.
9. The .Net Framework: Richness.The .Net Framework is a rich source of tools and capabilities that many SharePoint developers neither know much about nor tap to their benefit.
If you’re not using things like conditional compilation, reflection, serialization, tracing, generics, anonymous types, nullable types, etc. to your advantage then the next book you buy should not be a SharePoint book. It should be a good reference on .Net for whichever language you prefer (C# or VB).
10. Invest the Time: You need to spend time perfecting your craft – writing code. This list is only the beginning. Carve out a couple of hours each and every week to read about coding, read source code and write code on your own.
Scott Hanselman has had a series on his blog for over three years now called “The Weekly Source Code” in which he blogs about code he reads. This is a guy that knows his stuff better than most and is arguably busier than any two of the rest of us combined and yet he still finds the time to work on his craft. Why don’t you?
We, as practitioners, need to stop hiding behind the myth that writing SharePoint code is hard. It’s not.
If every one of us starts taking steps to improve our development practices then the average quality of SharePoint solutions will skyrocket. That’s something we would all benefit from.