Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Fighting Complexity in Elixir

Mrinal Wadhwa
September 19, 2020

Fighting Complexity in Elixir

This talk discusses how several ideas from John Ousterhout's book "A Philosophy of Software Design" can be applied to Elixir code.

Mrinal Wadhwa

September 19, 2020
Tweet

More Decks by Mrinal Wadhwa

Other Decks in Programming

Transcript

  1. The greatest limitation in software is our ability to understand

    the systems we are creating. — John Ousterhout, A Philosophy of Software Design
  2. As we add new features, our code evolves and naturally

    becomes more complicated. Subtle dependencies emerge.
  3. It becomes harder and harder for us to keep all

    of the relevant information in our minds … Over time, this complexity accumulates.
  4. Because the system is becoming complex and we’re struggling to

    keep all the details in our minds: It becomes harder to add new features … it slows us down.
  5. Because the system is becoming complex and we’re struggling to

    keep all the details in our minds: We can easily miss some detail and create bugs … which further slows us down. It becomes harder to add new features … it slows us down.
  6. Stamina Simpler, less complex, designs allow us to build larger

    more powerful systems before complexity becomes overwhelming. Its about building:
  7. Complexity Anything related to the structure of a codebase that

    makes it hard to understand or improve that codebase.
  8. Unknown unknowns Symptom 3: It’s not obvious which pieces of

    code must be modified to complete a task, or what information a developer must have to carry out the task successfully.
  9. Tactical Programming In the tactical approach, our main focus is

    to get something working. This is how systems become complicated - one small compromise at a time.
  10. Strategic Programming The first step towards becoming a good software

    designer is to realize that working code isn’t enough. It’s not acceptable to introduce unnecessary complexities in order to finish your current task faster. The most important thing is the long-term structure of the system. Our primary goal must be to produce a great design, which also happens to work. This is strategic programming. – John Ousterhout. A Philosophy of Software Design
  11. The simple parts of reducing Cognitive Load … Good names,

    good comments, consistency, mix format, credo etc.
  12. Modular Design A developers only need to face a small

    fraction of the overall complexity at any given time.
  13. Encapsulation Encapsulate complexity so our team can work on other

    parts of the system without being exposed to the complexity encapsulated in this module.
  14. Deep Modules The best modules are those that provide powerful

    functionality yet have simple interfaces.
  15. With a sufficient number of users of an API, it

    does not matter what you promise in the contract: all observable behaviours of your system will be depended on by somebody. Hyrum's Law: Use defp.
  16. Loose Coupling Components in a loosely coupled system can be

    replaced with alternative implementations that provide the same services.
  17. Messages Processes can send messages to other processes without needing

    to care what the receiver process is or does. The interface is Process IDs and Kernel.send/2
  18. Protocols A group of function headers that a data type

    must implement if it is considered to be implementing that protocol.
  19. Dependency Inversion High-level modules should not depend on low-level modules.

    Both should depend on abstractions (e.g. interfaces). Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions..