Skip to content

Instantly share code, notes, and snippets.

View kopepasah's full-sized avatar
🤖
Solving problems with bots.

Justin Kopepasah kopepasah

🤖
Solving problems with bots.
View GitHub Profile
@kopepasah
kopepasah / 0_reuse_code.js
Created May 31, 2014 14:41
Here are some things you can do with Gists in GistBox.
// Use Gists to store code you would like to remember later on
console.log(window); // log the "window" object to the console
@kopepasah
kopepasah / ddd.md
Created April 14, 2021 16:11 — forked from zsup/ddd.md
Documentation-Driven Development (DDD)

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

  • Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
  • Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
  • Once documentation has been written, development should commence, and test-driven development is preferred.
  • Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
  • When a feature is being modified, it should be modified documentation-first.
  • When documentation is modified, so should be the tests.