Given that Information Systems qualifications most often fall under the Commerce faculty banner, it is to be expected that most IS graduates emerge with a strong understanding of business concepts. Similarly, Computer Science graduates tend to be well-equipped to code complex architectures and applications and FET college graduates are equipped with a broad-based understanding of various programming languages. What these graduates seldom emerge with is a practical knowledge of the development tools and techniques that they will be exposed to on an almost daily basis in the work environment. These tools allow developers to collaborate, creating teams of highly skilled individuals focused on delivering innovative solutions uniquely tailored to the clients’ needs.

The Tools:

1.     Continuous Integration (CI) – aka Build Server

CI software is configured to automate the build of certain software projects without direct user integration. By creating automated, repeatable faster deployment processes the risk of errors, as well as the dependency on the developer’s time is significantly reduced. It also allows non-technical individuals to trigger builds, and for real-time and visual feedback, which normally takes the form of email notifications and various other graphic tools, accessed via a web portal. In an agile development team, a continuous build is vital for real-time feedback.

In order to implement CI you will need to select a lightweight CI tool such as TeamCity, Hudson or Jenkins. At BSG, the .Net team utilises JetBrains TeamCity as it is simple to set up and configure, lightweight in terms of resource requirements, supports multiple programming languages, includes a good code coverage tool and is free.

2.     Version Control System (VCS) – aka Source Control

VCS is software that allows developers to simultaneously work on the same source code files. The VCS tool is able to resolve merge conflicts, revert to previously saved versions and keep a history of changes as well as the usernames of the individuals that made the changes. This allows for safe collaboration and testing of code. Developers working in teams are discouraged from preventing team members editing files, except binary files, as this is counterproductive, especially in an agile development team. The most important thing is to continuously update the version of the source code you’re working from to ensure you are up-to-date with the rest of the team.

In the newer generation VCSs, known as Distributed VCS (DVCS), each developer has local access to the entire repository, which is usually cloned from a central location. In order to utilise VCS you will need a file-based DVCS, such as Mercurial or Git. In order to interact with the VCS you will need various client tools; for a more graphical experience try TortoiseHG for Mercurial or SmartGit/HD for Git, a merge tool is also required, KDiff is recommended. Finally, you will need the infrastructure to host your own repository, GitHub and BitBucket are two such services.

3.     Design Patterns

Design Patterns are reusable software solutions used to solve commonly occurring problems. In the same way that Patterns are a common way of correctly solving problems, Anti-Patterns are common ways of doing things wrong. Closely related to this is the concept of Code Smells, which is used to describe bad coding practices.

There are a few books and industry blogs that can help you to gain a better understanding of Design Patterns: Gang of Four (GoF), Patterns of Enterprise Application Architecture (Addison-Wesley Professional, 2003) by Martin Fowler, Head First Design Patterns (O’Reilly Media, Inc., 2004) by Elizabeth Freeman, et al. and PluralSight’s Design Pattern video course.

4.     Test Driven Development (TDD) – aka Test First Approach

TDD is a development approach where developers begin by writing unit tests that describe the intended functionality. The tests will initially fail as the functionality doesn’t exist yet, but they will begin passing as the code to change the state is added. This means the code is driven by tests and not the other way around. Although the advantages of TDD are numerous, TDD theory has not yet been incorporated into mainstream IS courses. TDD can direct developers to make better use of coding principles. It encourages developers to code smaller, reusable components and only the code that is required; this is better because more complex code is harder to maintain.

At BSG we divide a test into 5 sections:

• Arrange: set up variables and supporting code
• Assume: assert known state before action
• Action: method under test
• Assert: to ensure action performed worked correctly
• Abolish: clean up after test

In order to get started you will need a testing framework written in the same programming language as your source code, and a test runner (a piece of software to execute the tests).

5.     Object Relational Mapping (ORM)

ORM is two-way mapping between C# domain classes and SQL tables. The benefit of ORM is to reduce the amount of code required to map data between SQL queries and domain objects, specifically TSQL required for table definitions, basic CRUD operations and complex queries, to almost zero. Good ORM will also provide Change Tracking, Lazy Loading and Eager Loading. One of the by-products of ORM is that database schema can be easily regenerated and therefore supports concurrent updates. At BSG, the .Net team uses Entity Framework Code First, written by Microsoft, the code first approach, Linq providers, fluent API, built-in migration and seeding frameworks makes EF a solid choice for .Net ORM-based development.

6.     Inversion of Control Containers (IOC) – aka Dependency Injection Container

IOC is a software framework used to automate the building of complex objects and to manage their application lifecycle. IOC is responsible for building classes, especially ones with multiple dependencies and sub-dependencies, this occurs through the use of a dependency injection pattern. IOC is also used to manage the lifecycle of the object, which means that the lifecycle code that used to be included in the class can now be controlled by the container itself. By using an IOC you write very little code to create complex objects and manage their lifespan, one implementation can easily be swapped out for another and changes to the class hierarchy will require far fewer code changes across the application.

To download the full article, click here.