If you are reading this, you are probably familiar with some Object Oriented Programming. In order to participate in a team and have a sufficient development process, team-members should have a shared philosophy of how they develop software.
For this handbook you will need to know the SOLID principles:
S
ingle-ResponsibilityO
pen/CloseL
iskov Substitution PrincipleI
nterface Segregation PrincipleD
ependency Inversion Principle
Find your own source and notes, which can explain these principles in whatever way suiting you.
Furthermore, we strongly advise you to read the Clean Code book. This philosophy is industry standard and has been for many years, so acquiring this knowledge is a great investment.
task
a single capability in a software. Fx: make a link to the Home page on the about page.feature
a feature for the in a software, formed by a set of tasks. Fx: adding multiple profile imagesepic
a use case of the software. Fx: making a signup flow
Projects, developed by the team, should use the Atomic design.
- All Components must be in a file that starts with a capital letter. (Fx:
BlueButton.tsx
) atoms
should be files that are purely styled componentsmolecules
are components that are small, but contain more than just styled componentsorganisms
are more complex components that contain multiple molecules/atoms
- All pages should have a folder inside content that encapsulates page specific code.
βββ backend # Server/service related application
...
βββ client # Frontend related application
β βββ components # Atomic design
β βββ globals # Fx: colors.tsx, categories.json etc.
β βββ index # A single entry file
β βββ models/types # Model/types/codegen-files/data classes etc.
β βββ pages # Navigable singe views which implements components (top levels)
β βββ styles # Getting started guide
β βββ ... # package declaration and config/env files.
βββ readme.md
Per default do not use eslint or equivalent. Hover some projects will use eslint locally or on 'Git-Commit-Time'.
- Do not outcomment code. Use the vcs! If you commit regularly, you can always go back and find old code.
- Try to make the code compact. Do not have lines with one character. Fx:
//Illegal
<a
href="https://www.facebook.com/fundbrickscompany/"
rel="nofollow noopener"
>
<FBIcon
name={"facebook"}
/>
</a>
//Legal
<a href="https://www.facebook.com/fundbrickscompany/" rel="nofollow noopener"><FBIcon name={"facebook"} /></a>
By default you should as minimum have a production and a development environment and for most projects you will also need a staging environment. Although, in early stages of a project a production environment might seem overkill. However the team should make the system environment compatible from the beginning.
You MUST ALWAYS commit your code after finishing a task. Before you commit it is important that you test the functionality of the part of the system you've worked with. (TASKS)
You should create a branch for each feature. After you merge the branch into the development branch it is important that you test the functionality on the development branch. (FEATURES)
When merging the development branch into the staging/production environment, you should always test the whole system. (EPICS)
Never ever include any .env files, api keys or equivalent.