Make that prototype maintainable, and make it so that no 1 person is mission critical to project upkeep.
- Always being Explicit
- Require files in a readable, obvious maner (always use an index)
- Self Document your code (i.e. name vars and functions as what they do)
- Write DRY Confident Code
- It should read like a book, you should be able to follow it as if its a story all the way from the bootstrap file in. This should happen with as few unnecessary tangents as possible, flowing from one function to another without breaking the reader out of the main storyline. And characters should not appear out of nowhere as if they've always been there.
- Modularity of Files
- Building features / code as if they will be reused elsewhere even if it doesn't seem likely.
- Write code using the Onion Method. Make sure your code is built up of many reusable packages ( / files) that are required from the outside in.
- Universal Truth
- If a thing is a thing for 1 user, it should be expected for all users even if it is not turned on.
- Customizations don't mean a different truth per organization, it just means more granular switches within features for all clients.
- UI should be explicit and organized so that when showing and hiding fields and features, they continue to make sense in the global context of said universal truth.
- Correct Assumptions
- Always assume the client is right about their problem but not about their solution.
- Rubber duck the smallest of problems.
- Always ask questions, be persistent.
- Ignorance is bliss, always keep your modules ignorant of the outside world, don't assume context.
- Client Centered
- We will always triage based on current clients first, then clients we wish to onboard.
- Every feature or bug fix should be implemented with the idea that the client has to use it, and that they may not be the most adept at computer related activities.
- Don't give users a map, give them turn by turn directions, make sure each element of the ui flows into the next automatically leading them to where they should be.
- Not all features the client will ask for are features that the Clients in general will be better off having, what is the over all effect of any feature or bug on the group as a whole, and then work the problem from there down to the individual client.
- Clarity of Goals
- We will not execute on anything until we have received clear goals.
- We will pursue the source of the goal until we reach a clear understanding.
- We will note said clear understanding in our assigned "card", "story", or "task".
- Side effects First
- When we assess a feature request or bug fix it must be assessed by side effects first, functionality second.
- Side effects should always be the priority meaning current functionality should never degrade
This is the least explicit, and hardest to trace way to accomplish the use of foreign code
module.exports = ()=>{
Users.find()
}
This is a mediocre, and simple solution for the inclusion and use of foreign code
module.exports = (system)=>{
system.controllers.Users.find()
}
This is a tedious but the most explicit and easiest to trace way to include and use of foreign code.
const {Users} = require('/src/models');
module.exports = ()=>{
Users.find()
}
Always make your requirements at the top of the file and all definitions should appear after that.
If you auto require a file, on requirement it may fail, and be difficult to trace. A whole lib might not load instead of explicitly saying what file was erroring.
const files = {}
["a", "b"].forEach((key)=>{
files[key] = require(key)
})
items/
index.js
a.js
b.js
c.js
d.js
const a = require('./a')
const b = require('./b')
const c = require('./c')
const d = require('./c')
modules.exports = {
a,
b,
c,
d
}
Code on the inside should never require code or resources on the outside, but code on the outside can and should require code and resources on the inside.
Private Model Helpers Public Models
Public Serializers Helpers Public Parameter Collection Helpers ()
Private Controller Helpers Public Controllers
/events/
/helpers
action.js
index.js
a.js
b.js
c.js
module.exports = (events)=>{
const eventHandler = async ({type, payload} = {})=>{
const eventReducers = async (i, action)=>{
if(events[i]){
action = await events[i]({
type: action.type,
payload: {...action.payload}
})
return eventReducers(
i + 1,
action
)
}else {
return action
}
}
return await eventReducers(0, {
type,
payload
})
}
return eventHandler;
}
const eventHandler = require('/events/helpers/eventHandler')
const a = require('a')
const reducers = eventHandler([
a,
b,
c
])
module.exports = ({type, payload})=>{
reducers({
type,
payload
})
}
const {vetter} = require('/integrations')
module.exports = async ({type, payload} = {})=>{
switch(type){
case 'CREATE_RESERVATION':
const response = await vetter.reservations.create({
provider: {
id: payload.externalId,
name: payload.name
}
})
return {
type,
payload: {
... payload,
vetter: response
}
}
default:
return {
type,
payload
}
}
}
EventThing.emit('abc', other)
EventThing.on('abc', (data)=>{
// Do some stuff
})
They do not always properly error within a readable context. They are aften async anonymous functions sometimes even run in another process or next tick and will at times error in a way that is difficult to debug.
A function that is run from a file in the "standard" way will error on line x
A function that is anonymous and runs from an event binding will error from the event binding context instead of the file the initial function was defined in.