In practice, there are two things:

- crash on error - functions are just functions

The first one is counter intuitive to many programmer. Basically you use pattern matching aggressively, like this:

    def full_name(%{first_name: <<a::utf8, _::binary>>, last_name: <<b::utf8, _::binary>>}) do
      "#{a} #{b}"
    end

This code will work only if a map/struct with the correct non null field are passed. The pattern match utf8 string of at least 1 valid utf8 character. Any other argument will crash.

Crashing in elixir is the way to handle unexpected things. For example, you will do:

    {:ok, myobject} = DB.get....

And if the DB fails (something unexpected), it will crash, the process will be restarted and the live view connected remounted and it will start again from a clean state.

Of course, error that are expected should be handled.

The second thing with elixir, is that functions are decoupled from data. You can move them around easily. For example, the above function will work on any struct with the correct fields and a plain map. But you can pattern match on specific struct too, which makes the code more like OOP, but it is more rarely done.

The key idea is to restrict code paths to something you expect, and always be explicit about what to expect.

When it comes to refactoring, the fact that Elixir is compiled helps a lot - there are a set of mistakes you make during a refactor which the compiler will just catch for you.