Skip to content

Instantly share code, notes, and snippets.

@rhwy
Last active May 8, 2023 22:10
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save rhwy/1219155ba4c0784f21fcf9cb93f5a78d to your computer and use it in GitHub Desktop.
Save rhwy/1219155ba4c0784f21fcf9cb93f5a78d to your computer and use it in GitHub Desktop.

FIST Principles

We believe in a set of distilled core rules that help us write and maintain better code that matters and ages well.

We embrace these concepts as core values that drive our decisions in design and implementation.

We appreciate the values of SOLID, FIRST, KISS, and YAGNI but feel the need for a set of more common principles that tie them all together.

FIST is an acronym that stands for:

  • Focus
  • Isolated
  • Small
  • Testable

Focus

The Focus rule means that code should always have a purpose and a use case. We avoid writing generic or technical code without a good business reason or a motive that emerges from refactoring. We do not design for reuse; reuse is a consequence of good design. The intent should be as clear and straightforward as possible.

Isolated

Elements of software should always be, at all levels, isolated from other parts of the system as much as possible. This principle applies from the code level to the package level. We prefer duplicating technical code over creating an unjustified dependency. We don't want future changes to harm existing code. At least, we want to minimize it and make it easy through continuous refactoring. Let the parts know about each other as little as possible. Abstractions are essential in this process and this could only works with low coupling and high cohesion.

Small (& Simple)

Complexity is everywhere; keeping things small is the only way to maintain a sane projection of reality that everyone can understand. The composition of small parts is always easier to manage than a larger one that conceals some concepts. The less code you have, the fewer bugs you'll generate. We'll always strive for simplicity over easiness through the creation of small parts that contain the essence of a concept or a use case. Aim to make things fit on our screen to avoid befferisation in our heads and context switching.

Tested

Elements of software should always be independently testable. Keeping things testable ensures confident evolution. It means there are no hidden parts causing external effects. Testing enforces emergent architecture and a style of design that promotes the other values. It also helps to prove, at least, some level of quality. It is a design concept that brings, at least, the proof of absence of known defects.

We believe that all these values are interdependent and that we achieve their true power by respecting them all. We don't say it's easy, not the guide to respect them, but just that these are the foundations of any work around software whatever the tool or context you're working.

@dupdob
Copy link

dupdob commented Mar 10, 2020

See a proposed improvement here (https://gist.github.com/dupdob/218524bd7f0b4bba33742e14501ce748)
Mostly english fix ups

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment