Skip to content

Instantly share code, notes, and snippets.

@dupdob
Forked from rhwy/FIST PRINCIPLES.md
Created March 10, 2020 10:54
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save dupdob/218524bd7f0b4bba33742e14501ce748 to your computer and use it in GitHub Desktop.
Save dupdob/218524bd7f0b4bba33742e14501ce748 to your computer and use it in GitHub Desktop.

FIST PRINCIPLES

We believe in a set of distilled core rules of that helps us writing and keeping better code that matters and ages well. We believe in these concepts as core values that drive our decisions in design and implementation. We believe that SOLID, FIRST, KISS, YAGNI and other.

FIST is an acronym that stands for:

  • Focus
  • Isolated
  • Small
  • Testable

Focus

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

Isolated

Elements of software should always be, at all levels, isolated from other parts of the systems as much as possible. This is true from code level to package level. We favor duplication of technical code over creating an unjustified dependency. We don’t want future changes to harm the existing code. At least, we want to minimize it and make it easy through continuous refactoring. Let’s parts know about each others as less as possible

Small (& Simple)

Complexity is everywhere, keeping things small is the only way to keep a sane projection of reality that you can explain to everyone. Composition of small parts is always simpler to manage than a bigger one that hides some concepts. Less code you have, less bugs you’ll generate. We’ll always try to follow simplicity over easyness through the creation of small parts that contains the essence of a concept, a use case. Try to make things fit on our screen.

Tested

Elements of software should always be independently testable. Keeping things testable is a guarantee for confident evolution. It means there is no hidden part having external effects. It is a glue for other values that helps proving, at least, some 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 the true power of them by respecting them all

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