En informatique, les propriétés ACID sont un ensemble de propriétés qui garantissent qu'une transaction informatique est exécutée de façon fiable.
Atomicité: L'atomicité est une propriété utilisée en programmation concurrente pour désigner une opération ou un ensemble d'opérations d'un programme qui s'exécutent entièrement sans pouvoir être interrompues avant la fin de leur déroulement. Une opération qui vérifie cette propriété est qualifiée d'« atomique », ce terme dérive de ατομος (atomos) qui signifie « que l'on ne peut diviser ».
Ce concept s'applique par exemple à une partie d'un programme dont le processus ou le thread qui la gère ne cédera pas le monopole sur certaines données à un autre processus pendant tout le déroulement de cette partie. Ce concept s'applique également aux transactions des bases de données.
La propriété d'atomicité assure qu'une transaction se fait au complet ou pas du tout : si une partie d'une transaction ne peut être faite, il faut effacer toute trace de la transaction et remettre les données dans l'état où elles étaient avant la transaction.
Cohérence: La propriété de cohérence assure que chaque transaction amènera le système d'un état valide à un autre état valide. Tout changement à la base de données doit être valide selon toutes les règles définies, incluant mais non limitées aux contraintes d'intégrité, aux rollbacks en cascade, aux déclencheurs de base de données, et à toutes combinaisons d'événements.
Isolation: Toute transaction doit s'exécuter comme si elle était la seule sur le système. Aucune dépendance possible entre les transactions. La propriété d'isolation assure que l'exécution simultanée de transactions produit le même état que celui qui serait obtenu par l'exécution en série des transactions. Chaque transaction doit s'exécuter en isolation totale : si T1 et T2 s'exécutent simultanément, alors chacune doit demeurer indépendante de l'autre.
Durabilité: La propriété de durabilité assure que lorsqu'une transaction a été confirmée, elle demeure enregistrée même à la suite d'une panne d'électricité, d'une panne de l'ordinateur ou d'un autre problème. Par exemple, dans une base de données relationnelle, lorsqu'un groupe d'énoncés SQL ont été exécutés, les résultats doivent être enregistrés de façon permanente, même dans le cas d'une panne immédiatement après l'exécution des énoncés.
SOLID
En programmation informatique, SOLID est un acronyme représentant cinq principes de bases pour la programmation orientée objet. Ils sont censés apporter une ligne directrice permettant le développement de logiciel plus fiable et plus robuste.
Responsabilité unique (Single Responsibility Principle): Une classe, une fonction ou une méthode doit avoir une et une seule responsabilité.
Ouvert/fermé (Open/closed principle): Une classe doit être ouverte à l'extension, mais fermée à la modification.
Substitution de Liskov (Liskov substitution Principle): Une instance de type T doit pouvoir être remplacée par une instance de type G, tel que G sous-type de T, sans que cela ne modifie la cohérence du programme.
Ségrégation des interfaces (Interface segregation principle): Préférer plusieurs interfaces spécifiques pour chaque client plutôt qu'une seule interface générale.
Inversion des dépendances (Dependency Inversion Principle): Il faut dépendre des abstractions, pas des implémentations.
KISS (Keep It Simple, Stupid)
Keep it simple, stupid (« garde ça simple, idiot », dans le sens de « ne complique pas les choses »), ou principe KISS, est une ligne directrice de conception qui préconise la simplicité dans la conception et que toute complexité non indispensable devrait être évitée dans toute la mesure du possible.
L'idée est de ne pas optimiser quoi que ce soit avant de maîtriser totalement une version simple de ce que l'on crée. Dans le produit fini, la simplicité d'usage, même au prix de renoncer à quelques fonctionnalités, est aussi un moyen de séduire l'utilisateur qui maîtrisera pour sa part l'usage du produit.
DRY (Don’t Repeat Yourself)
DRY est une philosophie en programmation informatique consistant à éviter la redondance de code au travers de l’ensemble d’une application afin de faciliter la maintenance, le test, le débogage et les évolutions de cette dernière.
« Dans un système, toute connaissance doit avoir une représentation unique, non-ambiguë, faisant autorité »
Lorsque le principe DRY est bien appliqué, la modification d'un élément d'un système ne change pas les autres éléments non liés logiquement. De plus, tous les éléments liés logiquement changent uniformément, de manière prévisible et restent synchronisés.
Les PSR « Propose a Standards Recommendation » sont des recommandations validées par le PHP Framework Interoperability Group (PHP fig : site officiel) ayant pour objectif d’améliorer l’interopérabilité entre les frameworks PHP, et plus généralement entre les développeurs PHP. Il ne s’agit aucunement de normes ou de standards établis mais de recommandations qui tendent à le devenir. D’un sens, les PSR sont similaires aux RFC (Request For Comment) qui régulent désormais le monde des réseaux. Le but étant de tendre vers une harmonisation des méthodes de développements.
PSR-1: Basic Coding Standard
Tags PHP
Utiliser <?php ?> ou <?= ?>
Codage des caractères
Utiliser de l'UTF-8 without BOM
Side Effects
Un fichier doit contenir uniquement des déclaration (classes, functions, constants, etc),
ou uniquement de la logic (ini_set, include, echo, etc).
NO Déclarations et Side Effects.
// side effect: change ini settings
ini_set('error_reporting', E_ALL);
// side effect: loads a file
include "file.php";
// side effect: generates output
echo "\n";
// declaration
function foo()
{
// function body
}
OK Déclarations uniquement.
// declaration
function foo()
{
// function body
}
// conditional declaration is *not* a side effect
if (! function_exists('bar')) {
function bar()
{
// function body
}
}