Development Framework to guide our engineering processes and outcomes

Crenet-Software-Development-Framework.md

Framework Coverage

General Concepts

• Endpoint URL Definition
• Postman API Documentation
• Issue tracking via Github Issues
• Git Methodologies
  • Frequent small commits
  • Push task to branch whether complete or incomplete at end of day
  • Single issue per Gitflow feature branch
• Request Inputs
  • snake_case for object keys
  • clear and descriptive names
• Response Structure

Development

• Clear and readable names
  • Variables uses camelCase naming convention
  • Classes uses PascalCase naming convention
  • snake_cased variables from request input are destructured to their camelCase alternative
  • camelCase variable names from implementation are mapped to snake_cased key-value pairs for consumption by client
• Helper Functions
  • Higher level grouping by folder
  • Function name must follow camelCase naming convention
  • If you have 2 or more inputs into a function, define the function parameters as an object, not as individual parameters.
  • Function name must match function file name
  • Single function per file
  • Function must have single responsibility
• Abstract Packages and Library to consistent internal API interface
• Abstract 3rd party infrastructure to Providers
• Utilize MVCS methodology
  • Route -> Controller -> Service + Helper Functions
• Address any issue raised by the linters

Development Tools

• VSCode Extensions
  • Add new line to files
  • Atom Keymap
  • AdonisJS Extension
  • Todo Tree
  • Code Spell Checker
  • Document This
  • Edge template support
  • ESlint
  • Git History
  • Git Lens
  • Gitflow
  • GitLive
  • indent-rainbow
  • Paste and Indent
  • Project Manager
  • Sonarlint
  • Turbo Console Log
  • Typescript Importer

CLICK HERE TO FIND THE SONARLINT RULES TO BE CONFIGURED ON YOUR LAPTOP

MVCS (Model View Controller Service Pattern)

This is a variant of the popular MVC Pattern, the difference is instead of the business logic living inside the controller, certain aspects of the implementation is passed off to a Service class, the Service class is usually aimed at a specific Model contextually.

We have identified certain actions that can be performed against a Model which we have outlined as a guide for creating the Service Class. The details of this can be found here - Service Class Method Structure & Guide

The RCMS (SCRM) Pattern in use internally aligns with the SOLID principles and 3 Design Patterns

SOLID Principles

• Single Responsibility Principle (Model Service Classes dealing with just one thing)
• Open/Closed Principle (Service Offerings are open for extension but closed for modification via a consistent provider class API)
• Liskov Substitution Principle (changing the provider doesn't change what the code does)
• Interface Segregation Principle (Providers implement only the interface needed)
• Dependency Inversion (Service Hub + Providers)

Design Patterns

• Facade - Abstract functionality behind a facade (provider), makes change seamless [Internal Providers & Service Providers]
• Factory - build and instantiate a new provider
• Strategy - use different providers for a given service without changing the existing code base