Simple vs Clear
Designing the right back-end needs to be a balance between scalability and maintainability. Neglecting one of these to aspect can come and hunt you over a period of time.
Earlier this week, in an excess of abstraction, I ended up with a model that had only a few lines, so it was pretty simple. After I started to write the tests I started getting confused, so I needed a more clear solution.
Here is what I'm talking about:
A. Simple version:
- class Slot(models.Model):
- """
- This objects can be either an empty dashboard,
- a chart w/o an dashboard or
- a slot in a dashboard.
- """
- dashboard = models.CharField()
- chart = models.ForeignKey(Chart)
- position = models.CharField()
- user = models.ForeignKey(User)
B. Clear version:
- class Slot(models.Model):
- """
- This objects can be either an empty dashboard,
- a chart w/o an dashboard or
- a slot in a dashboard.
- """
- dashboard = models.ForeignKey()
- chart = models.ForeignKey(Chart)
- position = models.CharField()
- user = models.ForeignKey(User)
- class Dashboard(models.Model):
- name = models.CharField()
- name_slug = models.SlugField()
- user = models.ForeignKey(User)
- default = models.BooleanField()
You're going to argue that the first version can't do the same things as the second version. They both passed the same tests.
(A) can be versatile, but it's not as scalable as (B) and it's hard to understand by next person who will maintain my code.
(A) can be extended with all the fields in (B) too, but they imply additional checks everytime an object is save.
The clarity and the simplicity here are superficial and refer only to the number of lines. To a normal person it's easier to understand that a Dashboard has multiple Slots, compared to an entitiy that can be either Dashboard or Slot, depending on what attributes it has.
Tip: Write your code as if the person who will end up maintaining it is a psychopathic killer who knows where you live.
Leave a Comment :