Les bonnes pratiques sur SAP BTP S/4 HANA

Dans cet article, nous allons parler des bonnes pratiques sur SAP BTP S/4 HANA. Nous allons d’abord définir ce qu’est SAP BTP S/4 HANA, puis nous verrons les principes de base du clean code et de la programmation orientée objet (POO).

Enfin, nous verrons comment appliquer les bonnes pratiques du clean code et de la POO en pratique sur SAP BTP S/4 HANA. Nous verrons également quelques exemples de code qui respectent les principes du clean code et de la POO.

En suivant les bonnes pratiques que nous allons voir, vous pourrez produire du code de qualité sur SAP BTP S/4 HANA qui sera lisible, maintenable et évolutif.

Qu’est-ce que SAP BTP S/4 HANA ?

SAP Business Technology Platform (BTP) est une plateforme de services cloud conçue pour développer, étendre et intégrer des applications. Basée sur SAP Cloud Platform, elle propose des services de gestion des données, d’analyse, d’intelligence artificielle et d’intégration.

De son côté, SAP S/4 HANA est un système ERP qui optimise la gestion des processus métier. SAP BTP S/4 HANA combine les fonctionnalités de ces deux solutions, offrant ainsi une plateforme intégrée.

Orientée vers le développement front-end, SAP BTP permet de créer des applications au sein de l’écosystème SAP.

On peut l’utiliser de 2 manières différentes :

1. En Fiori SAPUI5
2. En natif SAPUI5

Fiori SAPUI5

Fiori est un Framework front-end basé sur de l’assemblage de composant UI5.

• Un Framework est un ensemble de composants logiciels qui fournit une architecture pour le développement d’applications.
• UI5 est un Framework de développement d’interface utilisateur basé sur HTML5, CSS et JavaScript.

Natif SAPUI5

Sur SAPUI5, on peut créer des applications web en utilisant des composants UI5. Ces composants sont des éléments d’interface utilisateur qui permettent de créer des vues et des contrôles pour les applications web. Les composants UI5 sont :

• Basés sur des modèles de données et des contrôleurs qui permettent de gérer les données et les interactions utilisateur.
• Conçus pour être réutilisables et extensibles, ce qui permet de créer des applications web modulaires et évolutives.

SAPUI5 permet également d’intégrer d’autres Framework front-end comme Angular, React, VueJS, etc.
Ce qui permet de créer des applications web plus complexes et plus riches en fonctionnalités. Cela ouvre de nouvelles perspectives pour le développement d’applications web sur SAP BTP S/4 HANA.

Importance des bonnes pratiques sur SAP BTP S/4 HANA

Pour aborder les bonnes pratiques sur SAP BTP S/4 HANA, il est essentiel de comprendre les principes fondamentaux du clean code.

Ce concept, introduit par Robert C. Martin dans son livre « Clean Code : A Handbook of Agile Software Craftsmanship« , englobe un ensemble de bonnes pratiques de programmation visant à produire un code lisible, maintenable et évolutif.

Définition et principes du clean code

Qu’est-ce que le clean code ?

Avant d’être une méthode, le clean code est une philosophie, du bon sens et de la rigueur.

Il est important de comprendre que le code est destiné à être lu par des humains et non par des machines. Il est donc essentiel de produire du code lisible, compréhensible et maintenable. Le clean code est un ensemble de bonnes pratiques de programmation qui permet de produire du code de qualité.

Principes de base du clean code

• Lisibilité
• Modularité
• Évolutivité
• Testabilité
• Performance
• Sécurité

Écrire du code lisible

Le code doit être facile à lire et à comprendre pour les développeurs qui le maintiendront.

Écrire du code modulaire

Le code doit être découpé en modules indépendants qui peuvent être réutilisés et testés séparément.

Écrire du code évolutif

Le code doit être conçu de manière à pouvoir évoluer facilement en fonction des besoins métier.

Écrire du code testable

Le code doit être testé automatiquement pour garantir son bon fonctionnement.

Écrire du code performant

Le code doit être optimisé pour garantir des performances optimales.

Écrire du code sécurisé

Le code doit être conçu de manière à garantir la sécurité des données et des utilisateurs.

Introduction à la Programmation Orientée Objet (POO)

Pour comprendre les bonnes pratiques du clean code, il est important de connaître les principes de base de la programmation orientée objet (POO). La POO est un paradigme de programmation qui permet de structurer le code en objets qui représentent des entités du monde réel.

Principes de la POO

• Héritage : les classes peuvent hériter des propriétés et des méthodes d’autres classes pour réutiliser du code.
• Encapsulation : les données et les méthodes d’un objet sont encapsulées dans une classe qui définit son comportement.
• Polymorphisme : les objets peuvent avoir des comportements différents en fonction de leur type.
• Abstraction : les classes abstraites permettent de définir des comportements génériques qui peuvent être implémentés par des classes concrètes.
• Interface : les interfaces permettent de définir des contrats entre les classes pour garantir une bonne communication entre elles.

Exemples de code illustrant le clean code et la POO

Héritage en JavaScript

class Animal {    
  constructor(name) {        
    this.name = name;    
  }    
  speak() {        
    console.log(`${this.name} makes a noise.`);    
  }
}

class Dog extends Animal {    
  speak() {        
    console.log(`${this.name} barks.`);    
  }
}

class Cat extends Animal {    
  speak() {        
    console.log(`${this.name} meows.`);    
  }
}

const dog = new Dog("Rex");
const cat = new Cat("Whiskers");

dog.speak();
cat.speak();

Comme on peut le voir dans cet exemple, les classes Animal, Dog et Cat respectent les principes de la POO en utilisant l’encapsulation, l’héritage, le polymorphisme et l’abstraction. De plus, le code est lisible, modulaire, évolutif, testable, performant et sécurisé, ce qui en fait un exemple de code propre et de qualité.

On obtient :

Rex barks.
Whiskers meows.

Encapsulation en JavaScript

class Counter {    
  #count = 0;    
  increment() {        
    this.#count++;    
  }    
  decrement() {        
    this.#count--;    
  }    
  getCount() {        
    return this.#count;    
  }
}

const counter = new Counter();
counter.increment();
counter.increment();
counter.decrement();

console.log(counter.getCount());

Dans cet exemple, la propriété #count est encapsulée dans la classe Counter en utilisant le mécanisme de private fields de JavaScript. Cela permet :

• de protéger la propriété #count et de garantir son intégrité en empêchant son accès direct depuis l’extérieur de la classe.
• également de garantir la cohérence et la cohésion du code en regroupant les données et les méthodes qui les manipulent dans une même classe.

On obtient :

1

Polymorphisme en JavaScript

class Shape {    
  getArea() {        
    return 0;    
  }
}

class Circle extends Shape {    
  constructor(radius) {        
    super();        
    this.radius = radius;    
  }    

  getArea() {        
    return Math.PI * this.radius ** 2;    
  }
}

class Rectangle extends Shape {    
  constructor(width, height) {        
    super();        
    this.width = width;        
    this.height = height;    
  }    

  getArea() {        
    return this.width * this.height;    
  }
}

const circle = new Circle(5);
const rectangle = new Rectangle(5, 10);

console.log(circle.getArea());
console.log(rectangle.getArea());

Dans cet exemple, les classes Shape, Circle et Rectangle respectent le principe du polymorphisme en redéfinissant la méthode getArea pour calculer l’aire d’un cercle et d’un rectangle. Cela permet :

• d’avoir des comportements différents en fonction du type de forme, tout en respectant le contrat défini par la classe Shape.
• également de garantir la réutilisabilité du code en permettant d’ajouter de nouveaux types de formes sans modifier le code existant.

On obtient :

78.53981633974483
50

Abstraction en Javascript

class Animal {    
  constructor(name) {        
    this.name = name;    
  } 
   
  speak() {        
    throw new Error("Method not implemented");    
  }
}

class Dog extends Animal {    
  speak() {        
    console.log(`${this.name} barks.`);    
  }
}

class Cat extends Animal {    
  speak() {        
    console.log(`${this.name} meows.`);    
  }
}

const dog = new Dog("Rex");
const cat = new Cat("Whiskers");

dog.speak();
cat.speak();

Dans cet exemple, la classe Animal est une classe abstraite qui définit une méthode speak qui doit être implémentée par les classes concrètes Dog et Cat. Cela permet :

• de définir un comportement générique pour tous les animaux et de garantir que les classes concrètes respectent le contrat défini par la classe abstraite.
• également de garantir la cohérence et la cohésion du code en regroupant les comportements communs dans une classe abstraite.

On obtient :

Rex barks.
Whiskers meows.

Interface en Javascript

interface Shape {    
  getArea(): number;
}

class Circle implements Shape {    
  constructor(private radius: number) {}   
 
  getArea(): number {        
    return Math.PI * this.radius ** 2;    
  }
}

class Rectangle implements Shape {    
  constructor(private width: number, private height: number) {}    

  getArea(): number {        
    return this.width * this.height;    
  }
}

const circle = new Circle(5);
const rectangle = new Rectangle(5, 10);

console.log(circle.getArea());
console.log(rectangle.getArea());

Dans cet exemple, l’interface Shape définit un contrat entre les classes Circle et Rectangle en spécifiant une méthode getArea qui doit être implémentée par ces classes. Cela permet :

• de garantir une bonne communication entre les classes en définissant un comportement commun qui peut être implémenté de manière différente par chaque classe.
• également de garantir la cohérence et la cohésion du code en regroupant les comportements communs dans une interface.

On obtient :

78.53981633974483
50

Code lisible vs code illisible

Exemple de code lisible en Javascript

/* * Calculate the area of a rectangle 
* @param {number} width - The width of the rectangle 
* @param {number} height - The height of the rectangle 
* @returns {number} The area of the rectangle 
*/
function calculateArea(width, height) {    
  return width * height;
}

/* * Calculate the volume of a box 
* @param {number} width - The width of the box 
* @param {number} height - The height of the box 
* @param {number} depth - The depth of the box 
* @returns {number} The volume of the box 
*/
function calculateVolume(width, height, depth) {    
  return width * height * depth;
}

const width = 5;
const height = 10;
const depth = 15;

// Calculate the area of a rectangle
const area = calculateArea(width, height);
const volume = calculateVolume(width, height, depth);

console.log(`Area: ${area}`);
console.log(`Volume: ${volume}`);

Exemple de code illisible en Javascript

function ca(width, height) {    
  return width * height;
}

function cv(w, h, d) {    
  return w * h * d;
}

const w = 5;
const h = 10;
const d = 15;

const a = ca(w, h);
const v = cv(w, h, d);

console.log(`Area: ${a}`);
console.log(`Volume: ${v}`);

Dans cet exemple, le code lisible utilise des noms de variables et de fonctions explicites qui permettent de comprendre facilement ce que fait le code. Le code est également bien structuré et bien commenté pour faciliter sa lecture et sa compréhension.

En revanche, le mauvais code utilise des noms de variables et de fonctions abrégés qui rendent le code difficile à comprendre. Le code est également mal structuré et mal commenté, ce qui rend sa lecture et sa compréhension difficiles.

Classe lisible en Javascript

class Rectangle {    
  constructor(width, height) {        
    this.width = width;        
    this.height = height;    
  }  
  
  getArea() {        
    return this.width * this.height;    
  }    

  getPerimeter() {        
    return 2 * (this.width + this.height);    
  }
}

const rectangle = new Rectangle(5, 10);

Classe illisible en Javascript

function createRectangle(width, height) {    
  return {        
    width: width,        
    height: height,        
    getArea: function () {            
      return this.width * this.height;        
    },        
    getPerimeter: function () {            
      return 2 * (this.width + this.height);        
    },    
  };
}

Dans cet exemple, le code lisible utilise une classe Rectangle pour représenter un rectangle avec des propriétés width et height et des méthodes getArea et getPerimeter pour calculer l’aire et le périmètre du rectangle. Le code est bien structuré et bien organisé, ce qui le rend facile à lire et à comprendre.

En revanche, le code illisible utilise une fonction createRectangle qui retourne un objet avec des propriétés et des méthodes. Le code est mal structuré et mal organisé, ce qui le rend difficile à lire et à comprendre.

Je pense que vous voyez maintenant l’importance du clean code et de la POO pour produire du code de qualité sur SAP BTP S/4 HANA comme ailleurs. Il est donc essentiel de respecter les principes du clean code et de la POO pour garantir la qualité, la maintenabilité et l’évolutivité du code.

Le clean code en pratique sur SAP BTP S/4 HANA

Maintenant que nous avons vu les principes du clean code et de la POO, voyons comment les appliquer en pratique sur SAP BTP S/4 HANA. Voici quelques bonnes pratiques à suivre pour produire du code de qualité sur SAP BTP S/4 HANA :

• Utiliser des noms de variables et de fonctions explicites : les noms de variables et de fonctions doivent être descriptifs et explicites pour faciliter la compréhension du code.
• Écrire des commentaires clairs et concis : les commentaires doivent expliquer le code de manière claire et concise pour faciliter sa lecture et sa compréhension.
• Structurer le code en modules indépendants : le code doit être découpé en modules indépendants qui peuvent être réutilisés et testés séparément.
• Écrire des tests unitaires et d’intégration : le code doit être testé automatiquement pour garantir son bon fonctionnement et sa qualité.
• Utiliser des outils de qualité de code : les outils d’analyse statique de code comme ESLint et Prettier permettent de détecter et de corriger les erreurs de code.
• Respecter les conventions de codage : les conventions de codage comme les règles de nommage et de formatage du code doivent être respectées pour garantir la cohérence du code.
• Éviter les duplications de code : le code dupliqué doit être extrait dans des fonctions ou des classes réutilisables pour éviter la redondance.
• Optimiser les performances du code : le code doit être optimisé pour garantir des performances optimales en évitant les opérations coûteuses.
• Sécuriser le code : le code doit être conçu de manière à garantir la sécurité des données et des utilisateurs en évitant les failles de sécurité.
• Documenter le code : le code doit être documenté pour expliquer son fonctionnement et son utilisation aux autres développeurs.

Si vous voulez allez plus loin, consultez le SAP Code Style Guides sur Github.

En suivant ces bonnes pratiques, vous pourrez produire du code de qualité sur SAP BTP S/4 HANA qui sera lisible, maintenable et évolutif. Cela vous permettra de développer des applications web performantes et sécurisées qui répondront aux besoins métier de l’entreprise.

Importance de la qualité du code pour SAP BTP S/4 HANA

Adopter les bonnes pratiques sur SAP BTP S/4 HANA est crucial pour produire un code de qualité, lisible, maintenable et évolutif. En appliquant les principes du clean code et de la programmation orientée objet, vous assurerez la robustesse et la pérennité de vos développements.

Ces pratiques vous permettront de créer des applications web performantes et sécurisées, répondant aux exigences métier de votre entreprise.

Rappelez-vous, le code est avant tout destiné à être lu et compris par des humains. Produire un code clair et bien structuré est donc essentiel pour sa maintenance et son évolution future. En intégrant ces bonnes pratiques, vous ferez de votre code un véritable atout pour votre organisation.

Ces bonnes pratiques vous parlent ? 👇