Refactoring – when it is a good time to perform?

When is a good time for refactoring? Theoretically – always. Practically… never. IT projects are (in)famous for being over budget and overdue…

Why?

There is a plenty of reasons that projects are getting out of control, however, certainly one of them is a technical debt. And the origin of this problem is delivering solutions which maybe work but are implemented without caring about readability. We tend to forget that the most time spent on coding by programmers is not actually ‘coding’ but… reading someone else’s code. There is a famous quote that fits here, you probably heard it already, but it is worth reminding:

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.

So what I did today? I refactored my code a bit 🙂

Maybe it looks that I did nothing, as application didn’t get any new look, functionality or so, but under the hood, it is more clear, easier to maintain and more ready to change.

As I told you lastly I temporary don’t have Azure (still!) so I’m using local file for DBMS purposes. But when it will finally go live again, I would like to switch to this approach easily.

Another thing is that Calendar Events are not the only objects that I’ll be using in my application, so I would like to be able to add new ‘repositories’ of objects. Again – easily.

(Re)solution

I decided to use Repository pattern here. I have something that would connect all my entity-classes which come in future:

[Serializable]
    public class IEntity
    {
        public string Id { get; set; }
    }

And it is Id field that surely is needed in each of them.

Additionally, I want to be sure that each repository will cover few fundamental methods:

public interface IRepository<T> where T : IEntity
    {
        void Add(T entity);
        void Delete(T entity);
        void Update(T entity);
        IEnumerable<T> List { get; }
        T FindById(string Id);
    }

And… that’s it roughly!

Now I created a repository for my Calendar Events (that’s a fragment only, for whole code look at feature branch):

public class CalendarEventRepository : IRepository<CalendarEvent>
{
    private readonly string path = @"C:\temp\db.txt";
    private IList<CalendarEvent> eventList;

    public IEnumerable<CalendarEvent> List
    {
        get
        {
            Deserialize();
            return eventList;
        }
    }
}

Now everything that concerns accessing data is hidden in the class above. Thanks to that I managed to reduce the amount of lines in HomeController by almost 100 lines! I like it!

And what is more important, adding new repositories and supporting them with data source won’t be a pain in the… neck. 🙂

Summary

I know that this is my side project and I can postpone the delivery date as much as I need actually. Thus I can do the refactoring as many times I wish to.

It is not so easy to tear enough time in business projects to do the job that is not valuable from investor/client perspective. Nonetheless, we always should forecast that such regular time boxes will be handy along the project lifecycle to make further development more pleasant or even… possible later. As I quoted Mariusz Gil in my discussion panel coverage: “Quality is not something we trade”. Avoiding refactoring stages is maybe time-saving in short term, but such behavior will surely strike back with (much) greater strength. Badly. Beware! 🙂

That’s all for today, folks! Thanks!