En tant que programmeurs, j'estime que notre objectif est de fournir de bonnes abstractions sur le modèle de domaine et la logique métier donnés. Mais où cette abstraction devrait-elle s'arrêter? Comment faire le compromis entre l'abstraction et tous ses avantages (flexibilité, facilité de changement, etc.) et la facilité de compréhension du code et de tous ses avantages.
Je crois que j'ai tendance à écrire du code trop abstrait et je ne sais pas à quel point il est bon; J'ai souvent tendance à l'écrire comme s'il s'agissait d'une sorte de micro-framework composé de deux parties:
- Micro-modules connectés au micro-framework: ces modules sont faciles à comprendre, à développer et à gérer en tant qu'unités individuelles. Ce code représente essentiellement le code qui exécute les tâches fonctionnelles décrites dans les exigences.
- Code de connexion; maintenant, je crois que le problème se pose. Ce code a tendance à être compliqué car il est parfois très abstrait et difficile à comprendre au début; cela est dû au fait qu'il ne s'agit que d'une abstraction pure, la base dans la réalité et la logique métier étant réalisées dans le code présenté 1; pour cette raison, ce code ne devrait pas être modifié une fois testé.
Est-ce une bonne approche en programmation? C’est cela, après avoir changé de code très fragmenté en de nombreux modules et très facile à comprendre et ne pas changer de code très complexe à partir du POV d’abstraction? Si tout le code est uniformément complexe (c'est-à-dire que le code 1 est plus complexe et interconnecté et que le code 2 est plus simple), afin que quiconque puisse le lire puisse le comprendre en un temps raisonnable, mais que le changement coûte cher ou que la solution présentée ci-dessus est bonne, où "Changer le code" est très facile à comprendre, déboguer, changer et "lier le code" est un peu difficile.
Remarque: il ne s'agit pas de lisibilité du code! Les codes 1 et 2 sont lisibles, mais le code 2 contient des abstractions plus complexes, tandis que le code 1 comporte de simples abstractions.