PyGrunn 2023: software design tips for lazy people - Arjan Egges

Tags: python, pygrunn

(One of my summaries of the May 2023 Dutch PyGrunn conference).

Arjan Egges runs the ArjanCodes youtube channel.

“Software design” often sounds like “huge diagrams with lots of arrows”. Sometimes software design is complicated, like determining what the customer actually wants. Or a big change in your mayor concept. Or fitting together completely different technologies, especially when they are opinionated.

What you also hear… “the code works, I don’t have time for refactoring”. “I have deadlines, and it works, so I don’t have to write tests”. “I just ask chatgpt to clean my code”.

His main point: software design is about consistently taking slightly different decisions while you’re coding. These decisions compound and should make you code faster and better.

He has seven tips for us:

  • Name wisely. This about categorising things. Being clear about what it is. Even better: a good name makes sure you yourself knows what something is :-) If you cannot find a good name for something, perhaps you should approach the problem in a different way? Perhaps you should turn your class into a couple of functions.

    If a function has “and” in the name: perhaps it should be split into two separate functions.

    If you use the word “library”, don’t use “lib” in other parts of the code. Be consistent.

    Use the naming scheme of the language that you use.

  • Use type annotations. It is extra work. But as you need to be explicit, it also ensures you have a better understanding of your own code.

  • Injecting dependencies. It is easier to later change your code. When you pass in a function to do something, you can later chanage the argument to a slightly different function. Your code is extensible.

    Composing your code in this way makes it easier to limit the amount of places where you tie everything together. It is also easier to test.

    The core is that you should make the concious design decision to approach most problems in this way. Your code will be cleaner and nicer.

  • Default to functions. Limit the amount of classes that you use to just what’s needed.

    Functions are easier to test than classes.

  • Don’t be greedy. If you only need a city name and a postal code, you don’t have to get an entire “Location” object with many other attributes. If you don’t need it, don’t request it.

  • Use abstraction. The abovementioned “Location” class could be abstracted into an “Address” class that has a couple of attributes less.

    Python has “protocol classes” that are super-useful for abstractions. But way too few people know about those. (I also didn’t know about them).

  • Be finicky. It is OK to be precise about what your function accepts. Your tests will be simpler. You’ll have to a little bit more work where you call the function, but that’s fine.

Apply these tips to your code and see where they bring you.

 
vanrees.org logo

Reinout van Rees

My name is Reinout van Rees and I program in Python, I live in the Netherlands, I cycle recumbent bikes and I have a model railway.

Weblog feeds

Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):