Two Ways To Keep Them

Alice in Userland

Story

Someone called Bob opens an issue on her repository.

Dear Alice,

I have been using your todo app and I think it would be great to sort todos alphabetically and limit the number of todos that will be returned.

Alice starts to answer and then stops. Her todos are one file each, so to put them in order she has to open every single one, sort them all in her own memory, and then throw most of them away. A folder does not know anything about order. A database does, so she teaches the app to keep todos in SQLite, where sorting and counting are part of the question she asks, and the work is finished before the todos ever reach her code. But Bob and everyone else already have a folder full of files, and she is not going to take that away from them. So she keeps both. TODO_STORAGE=sqlite chooses the database, and anything else, including saying nothing at all, leaves the folder exactly as it was.

Making room for the second one is where it turns ugly. Adding a todo asks which storage this is. Finishing one asks again. So do removing, listing, and looking a single todo up. The same question, over and over, in a slightly different shape each time, and every feature she adds from now on will have to ask it too. Alice reads her file back and knows that something is wrong with it. She does not have a name for it yet.

Alice's Notebook

  • Give every command its own function instead of writing its body inside the switch block.
  • Keep the code that reads the terminal apart from the code that knows what a todo is.
  • Handle different concerns in different parts of the program (Single Responsibility Principle).
  • Use a library for the work that is not your program’s real job.

Choose a file from the tree.