This is a post about code refactoring, the long journey of removing technical debts in the system I have built at work.
Since late 2015, I have been working on a system which is supposed to be extensible and scalable to support our branches in different countries. With the frequent change of user requirements and business strategies, mistakes and system-wide code refactoring are things that I can’t avoid.
Today, I’m going to list down some key lessons and techniques I learned in this one year plus of journey of clearing technical debts.
…we are not living in a frozen world of requirements and changes. So you can’t and shouldn’t avoid refactoring at all.
The risk in avoiding would definitely bring up messy codes, and tough maintenance of your software, you can leave it behind but somebody else would suffer.
— Nail Yuce, Author of the redbook “Collaborative Application Lifecycle Management”
Databases Organization
Originally, we have three branches in three countries. The branches are selling the same product, laptop. It’s business decision that these three branches should behave individually with different names so that customers generally can’t tell that these three branches are operated by one company.
Let’s say these three branches have names as such, Alpha, Beta, and Gamma. Instead of setting up different databases for the branches, I put the tables of these three branches in the same database for two reasons:
- Save cost;
- Easy to maintain because there will be only one database and one connection string.
These two points turn out to be invalid few months after I designed the system in such a way.
I’m using Azure SQL, actually separating databases won’t incur higher cost because of the introduction of Elastic Database Pool in Microsoft Azure. It’s also not easy to maintain because to put three business entities in one database, I have two ways to do it.
- Have a column in each table specifying the record is from/for which branch;
- Prefix the table names.
I chose the 2nd way. Prefix the table names. Hence, instead of a simple table name such as Suppliers, I now have three tables, APSupplier, BTSupplier, and GMSupplier, where AP, BT, and GM are the abbreviation of the branch names.
This design decision leads to the second problem that I am going to share with you next.
Problem of Prefixing Table Names
My senior once told me that experience was what made a software developer valuable. The “experience” here is not about technical experience because technology simply moves forward at a very fast pace, especially in web development.
The experience that makes a software developer valuable is more about system design and decision making in the software development process. For example, now I know prefixing table names in my case is a wrong move.
There are actually a few obvious reasons of not prefixing.
For those who are using Entity Framework and love intellisense feature in Visual Studio IDE, they will know my pain. When I’m going to search for Supplier table, I have to type the two-letter branch abbreviation first then search for the Supplier table. Hence in the last one year, our team spent lots of man hours going through all these AP, BT, and GM things. Imaging the company starts to grow to 20 countries, we will then have AP, BT, GM, DT (for Delta), ES (for Epsilon), etc.
To make things worse, remember that three branches are actually just selling the laptops with the similar business models? So what would we get when we use inheritance for our models? Many meaningless empty sub-classes.
public abstract class BaseSupplier
{
public int Id { get; set; }
public string Name { get; set; }
public string PersonInCharge { get; set; }
public string Email { get; set; }
public bool Status { get; set; }
}
public class APSupplier : BaseSupplier { }
public class BTSupplier : BaseSupplier { }
public class GMSupplier : BaseSupplier { }
So if we have branches in 20 countries (which is merely 10% of the total number of countries in the world), then our software developers’ life is going to be miserable because they need to maintain all these meaningless empty classes.
Factory Design Pattern and Template Methods
However, the design above actually at the same time also makes our system to be flexible. Now, imagine that one of the branches requests for a system change which requires addition of columns in its own Supplier table, we can simply change the corresponding sub-class without affecting the rest.
This leads us to the Factory Design Pattern. Factory Design Pattern allows us to standardize the system design for each of the branch in the same system while at the same time allowing for individual branch to define their own business models.
public abstract class SupplierFactory
{
public static SupplierFactory GetInstance(string portal)
{
return Activator.CreateInstance(Type.GetType($"Lib.Factories.Supplier.{portal}SupplierFactory")) as SupplierFactory;
}
protected abstract BaseSupplier CreateInstanceOfSupplier();
protected abstract void InsertSupplierToDatabase(BaseSupplier newSupplier);
public abstract IQueryable RetrieveSuppliers();
public async Task AddNewSupplierAsync(SupplierManageViewModel manageVM)
{
...
var newSupplier = CreateInstanceOfSupplier();
newSupplier.Name = manageVM.Name;
newSupplier.PersonInCharge = manageVM.PersonInCharge;
newSupplier.Email= manageVM.Email;
newSupplier.Status = manageVM.Status;
InsertSupplierToDatabase(newSupplier);
}
...
}
For each of the branch, then I define their own SupplierFactory which inherits from this abstract class SupplierFactory.
public class AlphaSupplierFactory : SupplierFactory
{
private AlphaDbContext db = new AlphaDbContext();
public override IQueryable RetrieveSuppliers()
{
return db.APSuppliers;
}
protected override void InsertSupplierToDatabase(BaseSupplier newSupplier)
{
db.APSuppliers.Add((APSupplier)newSupplier);
}
...
}
As shown in the code above, firstly, I no longer use the abbreviation for the prefix of the class name. Yup, having abbreviation hurts.
Secondly, I have also split the big database to different smaller databases which store each branch’s info separately.
The standardization of the workflow is done using Template Method such as AddNewSupplier method shown above. The creation of new supplier will be using the same workflow for all branches.
Reflection
public static SupplierFactory GetInstance(string portal)
{
return Activator.CreateInstance(Type.GetType($"Lib.Factories.Supplier.{portal}SupplierFactory")) as SupplierFactory;
}
For those who wonder what I am doing with the Activator.CreateInstance in the GetInstance method, I use it to create an instance of the specified type that type’s default constuctor with portal acts as an indicator on which sub-class the code should pick using reflection with the Type.GetType method. So the values for portal will be Alpha, Beta, Gamma, etc. in my case.
This unfortunately adds one more burden to our development team to pay attention to the naming convention of the classes.
Fluent API: ToTable
All these unnecessary complexity is finally coming to an end after my team found out how to make use of the Fluent API. Fluent API provides several important methods to configure entities which help to override Code First conventions. ToTable method is one of them.
ToTable helps mapping entity to the actual table name. Hence, now we can fix our naming issues in our databases with the codes below in each of the branch’s database context class.
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
base.OnModelCreating(modelBuilder);
modelBuilder.Entity().ToTable("APSuppliers");
... // mappings for other tables
}
With this change, we can furthermore standardize the behavior and workflow of the system for each of our branch. However, since we only start to apply this after we have expanded our business to about 10 countries, there will be tons of changes waiting for us if we are going to apply Fluent API to refactor our codes.
Technical Debts
I made a few mistakes in the beginning of system design because of lacking of experience building extensible and scalable systems and lack of sufficient time and spec given to do proper system design.
This naming issue is just one of the debts we are going to clear in the future. Throughout the one year plus of system development, the team also started to realize many other ways to refactor our codes to make it more robust.
As a young team in a non-software-development environment, we need to be keen on self-learning but at the same time understand that we can’t know everything. We will keep on fighting to solve the crucial problems in the system and at the same time improving the system to better fit the changing business requirements.
I will discuss more about my journey of code refactoring in the future posts. Coming soon!
cuteprogramming 