“Only a fool learns from his own mistakes. The wise man learns from the mistakes of others.” ― Otto von Bismarck
I've been programming Django for about six years now, so I've learned a lot (mostly the hard way, many of my own fault).
Per sourcemaking.com "An antipattern is a literary form that describes a commonly occurring solution to a problem that generates decidedly negative consequences."
- No ramifications at the time of implementation, but long term increased complexity.
- Seems like a good idea at the time. Doesn't seem hacky.
- "Already happens this area of the code. Let me just use this somewhere else ..."
- "This one line solves all my problems! I don't have to refactor!"
Django is a phenomenal framework that lets you build stable web end development quickly. However, an antipattern implemented with best intentions can become unwieldy. What Technical Debt Feels Like
- Corner case after corner case.
- Hotfixes for something that "worked on my machine"
- Implenting features that always requiring fixing other bugs completely unrelated
- Poor testing practices.
Django Docs on Signals. Signals are sometimes useful, but I have been burned so many times from things magically getting called that they are rarely worth the additional implementation cost. See : Lincoln Loop's post
All models start off pretty simple. Example: Dealership Inventory Management Software
class Car(models.Model):
name = CharField()
year = CharField()
created = DateTime(auto_now_add=True)The problem that frequently results is business logic is slowly introduced bit by bit. Eventually the file becomes so tightly coupled refactoring becomes too intimidating.
Day One
Product Manager : I want to know which cars are sold.
Engineer 1 : I'll add a time-sold, sold-at field and use that. I don't have to make a new model (CarsSoldRecord).
class Car(models.Model):
name = CharField()
year = CharField()
created = DateTime(auto_now_add=True)
time_sold = DateTime(null=True, blank=True)
sold_at = DecimalField(null=True, blank=True)Day Two