standards.lalalab.com Open in urlscan Pro
2606:4700:4400::6812:24e1  Public Scan

Form analysis
0 forms found in the DOM

Text Content

🧑🌾
🧑🌾
🧑🌾
🧑🌾
Lalalab Backend Standards

Search…
⌃K


🍕
Introduction
Getting Started
MoleculerJS
Overview
🍻
Common features
Write an action
Write an HTTP request
Write an async job
🍰
Technical features
Documentation
Unit Testing
Databases
Linter
Git & Releases
Powered By GitBook


GETTING STARTED


The white book new backend standards is written, is the "Coran book" that every
backend dev should have in his pocket :)

INTRODUCTION

Welcome to the official Backend Lalalab Standards. All Standards / Conventions /
Practices / Guides, have been discussed and decided with the all backend team
before to write them down in the book. Please keep this ritual, keep Cultural
Heritage and Collective Intellectual Property Rights, and never take a personal
emotional decision.
For the terminology, in lalalab we use Domain, that refers to a Microservice.
And distributed system = microservice pattern
PHILOSOPHY

The first important thing to note is that a coding standards document is not
about right and wrong. It’s not about good and bad or which method is better.
A coding standards document’s purpose is to make sure that all code is designed,
written and laid out the same to make it easier for a developer, to switch from
one to another person without the needed change of mentality to read someone
else’s style. It’s all about uniformity, and nothing about “Right and wrong”.
Then Standardized the code means, unify the recurrent problems/solutions.
> 5 Ninjas dev who pull hardly the project in 5 differents ways will not move 2
> Juniors dev who pull softly the project in 1 way will move up
> - "Bruno Sautron" - 2022

Non-quality :
Number of bugs
Product out of expectation
Speed to resolves bug (“oh, my minor bug is actually a hug deep bug”)

Quality :
More Simple, less code, less bug
Less boilerplate
More Tested code
Maintainable
Standardize (← Here we are)

PURPOSES

Those Standards will served on the day to dev development. More than increase
the rigor of each single dev, he will use it to :
REDUCE THE VARIATIONS IN THE CODE

More visibility
Easier to find and correct bugs

INCREASE QUALITY AND PRODUCTIVITY OF THE TEAM

Thought, debated and wrote only once, no need to think about in the day to day
Less wasp of time and energy

HAVE A BETTER VIEW ON THE PROCESS

The process is more predictable
Easier to plan and scheduled the development
Have ready-guides to follow

HAVE A BETTER COMMUNICATION

Better conversation
Less implicit
Less debate
Less MR/PR open times
Better rotation of dev in the team (ex: onboarding)

Next - Introduction
MoleculerJS

Last modified 5mo ago
Copy link
On this page
Introduction
Philosophy
Purposes
🍕
Introduction
Getting Started
MoleculerJS
Overview
🍻
Common features
Write an action
Write an HTTP request
Write an async job
🍰
Technical features
Documentation
Unit Testing
Databases
Linter
Git & Releases
Powered By GitBook