Do you document the technologies, design patterns and ALM processes?
30/07/2019 8:37 AM by
The technologies and design patterns form the architecture that is usually the stuff that is hard to change.
A pattern allows using a few words to a dev and he knows exactly what coding pattern you mean.
ALM is about refining the work processes.
- We are doing this project using C#
- Bad example - you know nothing about how the project will be done
Technologies: WebAPI. The DI container is Structure Map. Entity Framework. Typescript. Angular.
Patterns: Repository and Unit of Work (tied to Entity Framework to remove additional abstraction), IOC
ALM: Scrum with 2-week sprints and a Definition of Done including StyleCop to green
ALM: Continuous deployment to staging
- Good example - this tells you a lot about the architecture and processes in a few words
The important ones for most web projects:
Patterns: Single responsibly - if it does more than one thing, then split it.
Eg. If it checks the weather and gets data out of the database, then split it.
Patterns: Inversion of control / dependency injection
Eg. If your controller needs to get data, then you inject the component that gets the data.
Patterns: Repository/Unit of Work - repository has standard methods for getting and saving data. The code calling the repository should not know where the data lives.
Eg. A User Repository could be saving to Active Directory or CRM and it should not affect any other code
You may or may not choose to have an additional abstraction away from entity framework.
ALM: Scrum - kind of a pattern for your process.
Eg. Sprint Review every 2 weeks.
Mostly a senior architect should be added for that 1 day each 2 weeks.
The decisions the team makes regarding these 3 areas, should be documented in _Technologies.docx as per https://rules.ssw.com.au/do-you-review-the-documentation.
Do you feel this rule needs an update?