主播大秀

I鈥檓 Mark Neves, a technical architect on the DNA Refactor Project.

What is DNA?

Regular readers of the Internet Blog will know that DNA is the platform that supplies User Generated Content (UGC) in the form of comments, messageboard posts and the like to the 主播大秀 website. It also powers the moderation tools needed to manage this content. For a brief history of DNA and how it got its name please visit .

The DNA Refactor Project

The DNA Refactor Project is focused on rebuilding the DNA functionality using best-of-breed software engineering techniques. This blog post explains how DNA became what it is today and the plans for 鈥榬efactoring鈥� the code base into a modern architecture making the platform easier to maintain, faster to extend and portable to other platforms.

Evolution of the DNA Code Base

Coding began with the creation of the website back in 1999. It was initially a with a back end. Shortly after its inception the platform was acquired by the 主播大秀 and developed over the years using many technologies by approximately 24 different developers. (While researching this figure I naturally hoped to find that 42 developers had worked on it. Still, 24 is practically the same, digit-wise.)

The first major refactor was the move to . As you can see some admin functionality remained in Perl for a very long time. The second major change was the聽decision to implement all new features in in around 2006 and have, as a background task, the job of migrating existing C++ functions to C#.

Again, like the Perl code before it, some features and tools remain in the C++ code base to this day. With tight time scales and limited resources it鈥檚 always difficult to justify spending time rewriting or refactoring existing code. It鈥檚 an age old issue in software development.

The last major architectural development was to implement to expose functionality to support moderated comments (among other services), allowing the user-facing elements to be implemented on the central 主播大秀 application platform. This drives comments on 主播大秀 News and Sports pages as you see them today.

Why Refactor?

So why is the 主播大秀 investing in the refactoring of the DNA code base? After all, DNA has stood the test of time providing a rock solid, reliable platform for hosting UGC and Moderation Services even in the most demanding of situations (, moderated Twitter feeds during the Olympics and the extremely busy but now decommissioned ).

UGC is an important aspect of the 主播大秀 website and will remain so for the foreseeable future. The platform that delivers this requirement needs to be built for the future. Let鈥檚 examine the current DNA architecture to see where the issues lie:

With 24 developers working at different times over 14 years on the platform it鈥檚 not surprising that the code base is suffering from a little technical debt:

• Chunks of business logic can be found in all layers of the architecture making it extremely hard (if not impossible) to write proper unit tests. The only practical tests that can be written are functional end-to-end tests that can take a very long time to write and a long time to run.
• There鈥檚 lots of coupling between layers and within layers. This makes it harder to develop new features, fix bugs and reuse and extend existing functionality.
• DNA uses which is a great way of maintaining a good level of separation between the application code and database, but it is still too intimately known to the application code to be able to switch persistence technology without rewriting a lot of code.
• There鈥檚 still a lot of functionality in the legacy C++ and C# code. It would be great if all that functionality were exposed through RESTful APIs making it easy to supply alternative UIs and consumers.

Another aspect is that the current code base has a large amount of functionality that is no longer used. The 主播大秀 sold h2g2 a couple of years ago and at that point the considerable amount of functionality that h2g2 exclusively used became redundant. Add to that the code behind other decommissioned social network sites like 606, Action Network, Get Writing and and it鈥檚 clear that a lot of inactive code can be laid to rest.

This is by no means a criticism of the way DNA has evolved. DNA has had a number of very talented software engineers working on it over the years. The history of the product is long and interesting and the code base gets a lot of things right. The time has come to take a step back and see how we can do things even better.

The Brave New World

The engineers in the DNA team have always been keen to embrace best practices when developing software. The DNA Refactor project will result in a platform that embraces software development principles:

• S - Single responsibility principle: A class should have only a single responsibility.
• O - Open/closed principle: 鈥�software entities [鈥� ] should be open for extension, but closed for modification鈥�.
• L - Liskov substitution principle: 鈥�objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.鈥�
• I - Interface segregation principle: 鈥�many client-specific interfaces are better than one general-purpose interface.鈥�
• D - Dependency inversion principle: One should 鈥�Depend upon Abstractions. Do not depend upon concretions.鈥� Dependency injection is one method of following this principle.

Here鈥檚 what the new architecture will look like:

The main features are:

• Proper separation of concerns. Each layer does one job and one job only.
• The is in one place. What鈥檚 more it is modelled using , i.e. objects just concerned with the job of providing the functionality, oblivious to the complex subsystems around them, such as http requests and databases.
• There is no or presentation layer. The only way to use the functionality will be through the RESTful APIs. There will be no direct access to the APIs on the internet 鈥� functionality is exposed through 主播大秀 applications or specially written tools that support moderation and admin functions that can be built on any platform.
• Each layer has its own suite of unit tests. These tests are short, simple to write and quick to run making them practical in a scenario.
• Functional (BDD) tests are used to describe the behaviour of the whole system in the platform-independent language Gherkin.

It鈥檚 easy to see how you each layer could be ported to different platforms and technologies. The BDD tests would provide confidence that all the functionality has been ported successfully.

It would be interesting to hear your feedback/comments below.

Mark Neves is聽a technical architect.