2.3 Working as a team: Tools and structure

The choice of tools and how the team is structured is crucial for a successful application.
- Not entirely like KISS, but close too it. GitHub versus GitLab. Barebones hardware or Containerization.

Use Constant Innovation (CI) principles to test all code before committing
Breaking things is a natural process of software engineering, notably when working on a piece of code during a long period
Be informed that the codebase is broken
Be able to identify changes between versions, and potentially, get back in time to a previous codebase
- Github/GitLab diff-docs. Example: Branch -> Change -> Test -> Commit -> Pull Request -> Merge

Smaller more managable pieces make it easier to develop
Teams may even work in parallel (with caution)
A large codebase implies that the safe way to work is to split the app into pieces
Extract your core “non-reactive” functions, which we will also call the “business logic”, and include them in external files
- Non-vital linkages (data ingestion pipelines)
- Page Layout and theming (CSS or branding characteristics)
- Allows for expansion but won’t break the core

Select a Manager, maybe a stakeholder or project manager. Someone who may or may not work on the codebase but is aware and knowledgeable
Select one or more core developers skilled but specific in their field of study
Follow git workflow with issue tracking and managing pull requests