Planning for Regular Code Reviews
Your development lead or SharePoint
technical architect must plan time into the schedule to perform regular
(weekly or sprint) code reviews to ensure code produced adheres to
SharePoint 2013 development best practice.
- Code has been packaged for deployment so that it can be deployed to
various development, testing, user acceptance testing, preproduction,
and production environments.
- Code revisions have a revision history and appropriate comments in TFS.
- Code revisions have associated tasks, and the developer has not overridden your check-in requirements.
- Code has an appropriate level of logging and instrumentation.
- Using statements have been appropriately applied to release resources as early as possible.
- Code performs in run-time conditions when a component is hit; for
example, 1,000 times a second. Does the code hit a shared component
that will not cope under the load?
- Code profiling tools, such as ANTS Performance Profile, do not pick up badly performing code.
- Exception handling is present and appropriate. No empty “try catch”
blocks, and preferably “try catch finally” code blocks exist.
- Security-related checks include any code that runs with elevated
privileges and require elevated permissions. Ensure that sufficient
defensive checks have been put in place to reduce the attack surface.
- Code is written once and reused as much as possible.
- Code is not overly complex. It should not require a genius to
decipher and maintain. The ACID test for any code is, “Can someone else
maintain the code after the individual is no longer on the project?”
- HTML code complies with validation tools and meets the accessibility requirements of the customer.
All code must be peer reviewed, and final code should be signed off by your development or team lead.
Large Project Considerations
Large SharePoint projects have
challenges similar to any large project in which many people work on
the same goals. For example, these challenges may include unclear
(undefined) responsibilities, tasks, schedules, roles, and so on.
Challenges must be addressed by proper planning of not just the project
deliverables, but also the development, testing, and release process.
Large Project Life-Cycle Models
Especially with large projects, you
must have clear responsibilities and development processes defined for
the different features that are developed. The most common way to
handle large development projects in SharePoint is to divide the
features into multiple code projects and solution packages. That way,
each feature project can consume common and shared services from one
common framework. This means that, from a solution perspective, the
design would be similar to the one shown in Figure 1.
Figure 1
demonstrates how code and features could be efficiently divided between
multiple different Visual Studio projects and solution packages. Framework.wsp
contains abstract code, which can be used in any SharePoint deployment.
Good examples for this kind of code would be logging, caching, and
configuration services. Copying this kind of general code to each
Visual Studio project or code structure is a waste of resources because
it could be deployed and versioned as an individual package and then
used by different projects.
Individual projects (Project X and Project Y) are large projects that provide different features (refer to Figure 1).
Having a general, common solution package or code layer, you can easily
share project-dependent features between different individual features.
A good example of this kind of functionality would be custom master
pages, which are used in different site definitions or web templates.
This way, you could easily maintain and update UI-dependent
functionality without, for example, being forced to do changes on the
new feature or solution package.
Individual features in projects are divided into
individual Visual Studio projects and solution packages to maintain and
upgrade them individually. This way, these features could be
individually tested and verified, even if other functionality is not
available.
Customization architecture and deployment
architecture have a direct impact on the overall maintenance costs and
processes. Therefore, your model should be carefully planned based on
your requirements. The example in Figure 1
is suitable for independent software vendors (ISVs) that develop many
services for multiple customers. By separating framework layer code at
the deployment level, each project can take advantage of any new base
services introduced. Possible fixes can be performed to multiple
projects by updating an individual package. As a result, individual
project developers can concentrate on solving business logic
requirements.
Figure 2 demonstrates the flow of development in larger projects where the framework-level code is separated into its own layer.
In this model, development teams are responsible
for their own features, and dependencies are created for specific
versions. For example, a framework-level development team has its own
versioning model, and the team releases tested and verified versions on
a weekly or monthly basis. Individual feature development or projects
reference and use these stable and tested versions as their building
blocks.
feature teams can use any suitable
version of the framework that matches their requirements and schedule.
This kind of approach provides flexibility for the individual feature
teams when planning their development iterations and road map. If
multiple features or projects are deployed to the same target
environment (such as a SharePoint farm), projects must use the same
platform-level version. But if the features are deployed to multiple
targets (such as an intranet farm and Internet farm), features can use
different versions of the platform-level services.
From a road map-level planning point of view,
this kind of model requires a little bit more coordination to
implement. But in the long term, it will definitely produce a return on
investment by increasing productivity and decreasing time required in
the maintenance model.
This model doesn’t require tens of
developers on the team. This model is also suitable for smaller
development teams, where developers are shared between framework- and
feature-orientated projects.
