Si vous êtes dans le développement de logiciels, de nouvelles techniques, langages et concepts apparaissent tout le temps. Nous ressentons tous ces doutes lancinants de temps en temps: « puis-je suivre les changements et rester compétitif? »Prenez un moment et résumez une phrase de mon film préféré, Casablanca: « Les choses fondamentales s’appliquent, au fil du temps. »
Toutes les quelques semaines, nous revisitons certains des articles préférés de nos lecteurs de tout le long de l’histoire du site. Ce tutoriel a été publié pour la première fois en avril 2012.
Ce qui est vrai pour l’amour, est vrai pour le code.
Ce qui est vrai pour l’amour, est vrai pour le code. Les choses fondamentales s’appliqueront toujours. Si vous avez une compréhension des idées sous-jacentes du développement logiciel, vous vous adapterez rapidement aux nouvelles techniques. Dans ce tutoriel, nous allons discuter de trois principes de base et les mélanger avec beaucoup d’autres. Ils offrent un moyen puissant de gérer la complexité des logiciels. Je partagerai certaines de mes opinions et réflexions personnelles, qui, espérons-le, s’avéreront utiles lorsqu’il s’agira de les appliquer au code et aux projets du monde réel.
Principe – Ne vous répétez pas
Une stratégie de base pour réduire la complexité en unités gérables consiste à diviser un système en morceaux.
Ce principe est si important à comprendre, que je ne l’écrirai pas deux fois! Il est communément appelé par l’acronyme, DRY, et est apparu dans le livre The Pragmatic Programmer, d’Andy Hunt et Dave Thomas, mais le concept, lui-même, est connu depuis longtemps. Il fait référence aux plus petites parties de votre logiciel.
Lorsque vous construisez un grand projet logiciel, vous serez généralement submergé par la complexité globale. Les humains ne sont pas bons pour gérer la complexité; ils sont bons pour trouver des solutions créatives à des problèmes d’une portée spécifique. Une stratégie de base pour réduire la complexité en unités gérables consiste à diviser un système en parties plus pratiques. Au début, vous pouvez diviser votre système en composants, où chaque composant représente son propre sous-système qui contient tout le nécessaire pour accomplir une fonctionnalité spécifique.
Par exemple, si vous construisez un système de gestion de contenu, la partie responsable de la gestion des utilisateurs sera un composant. Ce composant peut être divisé en d’autres sous-composants, tels que la gestion des rôles, et il peut communiquer avec d’autres composants, tels que le composant de sécurité.
En divisant les systèmes en composants et, en outre, les composants en sous-composants, vous arriverez à un niveau où la complexité est réduite à une seule responsabilité. Ces responsabilités peuvent être implémentées dans une classe (nous supposons que nous construisons une application orientée objet). Les classes
contiennent des méthodes et des propriétés. Les méthodes implémentent des algorithmes. Les algorithmes et – selon l’obsession que nous voulons obtenir – les sous-parties des algorithmes
calculent ou contiennent les plus petites pièces qui construisent votre logique métier.
Le principe DRY stipule que ces petites connaissances ne peuvent se produire qu’une seule fois dans l’ensemble de votre système.
Ils doivent avoir une seule représentation en son sein.
Chaque connaissance doit avoir une représentation unique, sans ambiguïté et faisant autorité au sein d’un système.
Notez la différence entre l’élément de connaissance et sa représentation. Si nous implémentons la connexion à la base de données dans notre CMS, nous aurons un extrait de code qui initialisera le pilote de base de données, transmettra les informations d’identification et enregistrera une référence à la connexion dans une variable. L’extrait de code fait partie de la connaissance, il s’agit de savoir comment quelque chose est réalisé. La variable avec la référence à la connexion est la représentation de cette connaissance – et cela peut être utilisé par d’autres parties. Si les informations d’identification de la base de données changent, nous devrons modifier l’extrait de code – et non sa représentation.
Dans une application parfaite, chaque petit morceau de logique métier encapsule ses connaissances dans une représentation, à savoir une variable ou une propriété de classe.
Cette variable elle-même est encapsulée dans une classe qui peut être décrite comme une représentation d’une responsabilité. La classe est encapsulée dans un composant qui peut être décrit comme une représentation de la fonctionnalité.
Cela peut se faire jusqu’à ce que nous atteignions le niveau supérieur de notre projet logiciel, c’est-à-dire une pile de représentations de plus en plus complexes. Cette façon de voir la complexité des logiciels est appelée architecture modulaire, et DRY en est une partie importante.
Atteindre la sécheresse
DRY est une philosophie qui regroupe la logique en représentations.
Il existe de nombreuses façons d’atteindre la sécheresse. Hunt et Thomas ont suggéré (entre autres choses) des générateurs de code et la transformation des données. Mais, essentiellement, DRY est une philosophie qui regroupe la logique en représentations.
Comme chaque partie de votre application peut être vue comme une représentation, chaque partie expose des fragments spécifiques de votre logique sous-jacente: La gestion des utilisateurs expose l’accès aux utilisateurs enregistrés du CMS, la classe user représente un seul utilisateur et expose ses propriétés (comme le nom d’utilisateur). Il récupère les propriétés, via la représentation de la base de données.
Une architecture sèche et modulaire nécessite une bonne planification. Pour obtenir une hiérarchie de représentation de bas en haut, divisez votre application en une hiérarchie de parties plus petites logiquement séparées et laissez-les communiquer entre elles. Si vous devez gérer des projets plus importants, les organiser en composants et utiliser DRY dans les composants est une bonne idée. Essayez d’appliquer les règles suivantes :
- Faites une hiérarchie visuelle de votre application logicielle et mappez-y les composants principaux. Les projets complexes peuvent nécessiter une carte dédiée pour chaque composant.
- Si vous arrivez à un niveau de responsabilités connectées, vous voudrez peut-être passer aux diagrammes UML (ou similaires).
- Avant d’écrire un morceau de code, nommez sa hiérarchie dans votre projet logiciel. Définissez ce qu’il représente et assurez-vous de connaître son rôle dans le composant environnant.
- Définissez ce que la représentation doit exposer aux autres parties (comme les fonctions pour exécuter SQL dans un pilote de base de données) et ce qu’elle doit cacher (comme les informations d’identification de la base de données).
- Assurez-vous que les représentations ne reposent pas sur des représentations d’un autre niveau de complexité (comme un composant qui repose sur une classe dans un autre composant).
Le pilote de base de données est un exemple simplifié, car il y a beaucoup plus de couches impliquées dans le monde réel (comme une couche d’abstraction de base de données spécifique), et il y a beaucoup plus que vous pouvez faire pour encapsuler la logique – en particulier la plongée dans les modèles de conception. Mais même si vous venez de commencer à coder, il y a une chose à garder à l’esprit:
Lorsque vous vous retrouvez à écrire du code similaire ou égal à quelque chose que vous avez écrit auparavant, prenez un moment pour réfléchir à ce que vous faites et ne vous répétez pas.
Dans le monde réel, les applications 100% SÈCHES sont difficiles, voire impossibles, à réaliser. Cependant, les applications qui ne sont pas sèches à un degré inacceptable – et donc difficiles à maintenir – sont assez courantes. Par conséquent, il n’est pas surprenant d’apprendre que plus de 50% de tous les projets logiciels échouent – si vous jetez un coup d’œil au code.
Beaucoup de gens ont tendance à penser que le mauvais code est produit par de mauvais codeurs. D’après mon expérience, c’est vraiment une exception. Le plus souvent, un mauvais code est produit par de mauvais gestionnaires de comptes et une mauvaise configuration globale de la gestion des processus dans les entreprises.
Un mauvais code est rarement produit par de mauvais codeurs.
Un exemple
La sécheresse est obtenue par une bonne planification.
Par exemple, supposons que vous soyez embauché en tant que consultant technique par une entreprise qui a des problèmes de qualité et de maintenance du code. Vous passez en revue la source et vous voyez des hacks et une duplication de code – le code n’est pas Sec. C’est un symptôme de mauvaise qualité du code, ce n’est pas la raison. Si vous jetez un coup d’œil au système de contrôle de version – c’est-à-dire à l’historique du code – il y a de fortes chances que vous trouviez des hacks qui ont été introduits à des moments proches des échéances et des jalons. Prenez le temps d’examiner les modifications apportées et vous serez probablement confronté à un changement dans les exigences.
Comme indiqué ci-dessus, la sécheresse est obtenue par une bonne planification. Les changements forcés dans un délai difficile obligent les développeurs à mettre en œuvre des solutions sales. Une fois le code compromis, le principe de DRY est susceptible d’être complètement sacrifié lors de modifications ultérieures.
Il y a une raison pour laquelle les entreprises les plus prospères du secteur informatique ont été fondées par des personnes ayant une très bonne compréhension technique – ou même des codeurs eux-mêmes: Bill Gates, Mark Zuckerberg, Steve Wozniak, Steve Jobs, Larry Page, Sergey Brin et Larry Ellison savent (ou savaient) quels efforts sont nécessaires pour mettre en œuvre quelque chose. Au contraire, de nombreuses entreprises ont tendance à confier les exigences en matière d’ingénierie aux gestionnaires de comptes et la partie conceptuelle aux consultants en entreprise…des gens qui n’ont jamais rien mis en œuvre.
Par conséquent, de nombreux concepts techniques ne fonctionnent que dans Powerpoint, Photoshop et sur des écrans larges de 27 « . Cela a peut-être été une approche réussie à l’époque de sites Web plus ou moins statiques, mais ce n’est pas le cas de nos jours – avec des applications interactives sur plusieurs appareils. Parce que les codeurs sont les derniers de la ligne, ce sont eux qui doivent appliquer des correctifs rapides sur les erreurs du concept. Si cela est accompagné d’un gestionnaire de compte, qui ne peut pas résister à un client qui aime faire des changements de dernière minute, les plans sont jetés à la poubelle et quelque chose de rapide et sale est mis en œuvre. Le code devient unDRY.
Cet exemple est un peu extrême (néanmoins, j’ai été témoin de tels scénarios), mais il démontre que le DRY est un concept théorique, qui est contesté par diverses parties dans le monde réel. Si vous travaillez dans une entreprise qui vous oblige à travailler de cette manière, vous pouvez suggérer des modifications au processus (comme l’introduction d’une expertise technique à un stade précoce des projets techniques).
Si vous avez une approche pratique, continuez à lire! Le principe Tu n’en auras pas besoin viendra à la rescousse.
Principe – Restez simple Stupide
L’explication la plus simple a tendance à être la bonne.
À la fin du 19ème siècle, les physiciens ont eu du mal à expliquer comment la gravité, le magnétisme et l’optique interagissent, lorsqu’il s’agit de grandes distances – comme les distances de notre système solaire. Par conséquent, un milieu nommé éther a été postulé. Il a été dit que la lumière voyage à travers ce médium et qu’elle est responsable d’effets qui ne pourraient pas être expliqués autrement. Au fil des ans, la théorie a été élargie avec des hypothèses qui ont ajusté le postulat de l’éther aux résultats des expériences. Certaines hypothèses étaient arbitraires, d’autres posaient d’autres problèmes et toute la théorie était assez complexe.
Un employé de l’Office suisse des brevets, Albert Einstein, a suggéré de se débarrasser de toute la théorie de l’éther en introduisant une idée simple, mais révolutionnaire: Toute l’étrangeté du calcul avec de grandes distances disparaîtrait si nous acceptions que le temps n’est pas une constante; c’est relatif. Cette pensée incroyablement prête à l’emploi pour arriver à l’explication la plus simple avec le moins d’hypothèses pour choisir entre des scénarios concurrents est appelée Rasoir d’Ockhams.
Il existe des concepts similaires dans de nombreux domaines. Dans le développement de logiciels (et autres), nous l’appelons KISS. Il existe de nombreuses variantes pour cet acronyme, mais elles signifient toutes que vous devez vous efforcer de trouver la manière la plus simple de faire quelque chose.
HTTP
Le protocole de transfert hypertexte est largement considéré comme un exemple parfait pour une solution simple: conçu pour transférer des documents hypertextes, il constitue aujourd’hui l’épine dorsale des applications hautement interactives et de bureau. Peut-être que nous devons trouver des solutions aux limitations du protocole, et peut-être que nous devons le remplacer un jour. Cependant, le statu quo est le suivant : basé sur quelques méthodes de requête (comme GET et POST), des codes d’état et des arguments en texte brut, HTTP s’est avéré flexible et robuste. C’est pourquoi HTTP a été repoussé à plusieurs reprises par les développeurs Web – et est toujours debout.
Nous prenons cette approche pour acquise, mais l’histoire du développement et de la normalisation de logiciels regorge de solutions trop complexes et à moitié cuites. Il y a même un mot inventé dédié pour cela: bloatware. Un logiciel comme celui-ci est également décrit comme étant DOD, mort à l’arrivée. J’ai une théorie très similaire à ma théorie du code unDRY, en ce qui concerne le bloatware… Cependant, le succès d’Internet peut être décrit comme un succès de solutions simples mais efficaces.
Alors, que faut-il pour arriver à la solution la plus simple possible? Tout se résume à la maintenabilité et à la compréhensibilité dans le développement de logiciels. Par conséquent, KISS intervient pendant la phase d’ingénierie des exigences. Lorsque vous réfléchissez à la façon de transformer les exigences d’un client en composants implémentables, essayez d’identifier les parties suivantes :
- Fonctionnalité qui présente un rapport inapproprié entre les avantages et les efforts.
- Fonctionnalité qui dépend fortement d’autres fonctionnalités.
- Fonctionnalité susceptible de gagner en complexité.
Il y a beaucoup de personnes impliquées dans le processus conceptuel, qui n’ont pas l’expertise technique pour faire une analyse coût-bénéfice fiable
Je travaillais autrefois sur un projet, où le client voulait importer des feuilles de calcul Excel dans son logiciel de gestion d’équipage. C’était un match clair. Excel est un logiciel propriétaire au format de document complexe. Le format est complexe, car il est riche en fonctionnalités : vous pouvez y ajouter des graphiques et d’autres éléments – des fonctionnalités qui n’étaient pas nécessaires au client. Il était simplement intéressé par les chiffres. Ainsi, la mise en œuvre de l’importation Excel nécessiterait la mise en œuvre de nombreuses fonctionnalités inutiles. En plus de cela, il existe plusieurs versions des versions d’Excel, et Microsoft déclenche une autre version chaque année. Cela aurait été difficile à maintenir, et cela entraîne des coûts supplémentaires à l’avenir.
Nous avons fini par implémenter une importation de valeurs séparées par des virgules. Cela a été fait avec quelques lignes de code. La surcharge des données était vraiment faible (comparez une feuille Excel à son équivalent CSV) et la solution était maintenable et à l’épreuve du temps. Excel était de toute façon prêt à exporter CSV (ainsi que d’autres programmes que le client pourrait vouloir utiliser à l’avenir). Comme la solution était également à bas prix, c’était une bonne application du principe KISS.
Pour résumer: essayez de penser hors de la boîte si une tâche vous semble compliquée. Si quelqu’un vous explique ses exigences et que vous pensez que ce sera difficile et complexe à mettre en œuvre, vous avez raison dans presque toutes les circonstances. Bien que certaines choses soient difficiles à mettre en œuvre, les solutions trop compliquées sont tout à fait habituelles. C’est le cas parce qu’il y a beaucoup de personnes impliquées dans le processus conceptuel, qui n’ont pas l’expertise technique pour faire une analyse coûts-avantages fiable. Par conséquent, ils ne voient pas le problème. Vérifiez si les exigences sont vraiment réduites à l’essence dont le client a besoin. Prenez le temps de discuter des points critiques et d’expliquer pourquoi d’autres solutions pourraient être plus appropriées.
Principe – Vous « N’En Aurez pas Besoin
Le codage consiste à construire des choses.
Lors du lancement de Google+, Mark Zuckerberg – fondateur de Facebook – a été l’un des premiers à créer un compte sur le réseau social qui visait à prendre le sien. Il a ajouté une seule ligne à la section À propos de moi: « Je construis des choses. ». Je pense honnêtement que c’est une phrase brillante, car elle décrit l’essence pure du codage en quelques mots simples. Pourquoi avez-vous décidé de devenir codeur ? Enthousiasme pour les solutions techniques ? La beauté de l’efficacité ? Quelle que soit votre réponse, ce n’est peut-être pas « construire le 1.000.001e site web d’entreprise avec des fonctionnalités standard « . Cependant, la plupart d’entre nous gagnent de l’argent de cette façon. Peu importe où vous travaillez, vous serez probablement confronté à des tâches ennuyeuses et répétitives de temps en temps.
80% du temps consacré à un projet logiciel est investi dans 20% des fonctionnalités.
Le principe Vous n’en aurez pas besoin (YAGNI) traite de ces tâches. Cela se traduit essentiellement par: Si ce n’est pas dans le concept, ce n’est pas dans le code. Par exemple, il est courant d’abstraire l’accès à la base de données dans une couche qui gère les différences entre les différents pilotes, tels que MySQL, PostgreSQL et Oracle. Si vous travaillez sur un site Web d’entreprise hébergé sur une pile LAMP, sur un hôte partagé, quelle est la probabilité qu’ils modifient la base de données? Rappelez-vous que le concept a été écrit avec le budget à l’esprit.
S’il n’y a pas de budget pour l’abstraction de base de données, il n’y a pas d’abstraction de base de données. Si l’événement improbable d’une modification de base de données se produit, il est naturel de facturer la demande de modification.
Vous avez peut-être remarqué la différence entre Vous n’en aurez pas besoin et les architectures modulaires pilotées à SEC: La seconde réduit la complexité en divisant un projet en composants gérables, tandis que la première réduit la complexité en réduisant le nombre de composants. YAGNI est similaire au principe du BAISER, car il cherche une solution simple. Cependant, KISS cherche une solution simple en essayant de mettre en œuvre quelque chose aussi facilement que possible; YAGNI cherche la simplicité en ne l’implémentant pas du tout!
Theodore Sturgeon, un auteur américain de science-fiction, a déclaré la loi: « quatre-vingt-dix pour cent de tout est de la merde ». C’est une approche très radicale, et pas trop utile dans les projets du monde réel. Mais gardez à l’esprit que la « merde » peut prendre beaucoup de temps. Une bonne règle empirique est la suivante: environ 80% du temps consacré à un projet logiciel est investi dans 20% des fonctionnalités. Pensez à vos propres projets! Chaque fois que je le fais, je suis surpris par l’exactitude de la règle 80:20.
Si vous êtes dans une entreprise réputée pour ses délais serrés et ses concepts imprécis, c’est une stratégie puissante. Vous ne serez pas récompensé pour l’implémentation d’une couche d’abstraction de base de données. Il y a de fortes chances que votre patron ne sache pas ce qu’est même une couche d’abstraction de base de données.
Bien que ce concept puisse paraître simple, il peut être difficile de distinguer les parties nécessaires des parties inutiles. Par exemple, si vous êtes à l’aise avec une bibliothèque ou un framework qui utilise l’abstraction de la base de données, vous ne gagnerez pas beaucoup de temps à la vider. Le concept clé est une autre façon de voir les logiciels: nous sommes formés pour écrire des logiciels évolutifs et maintenables. Cela signifie que nous sommes formés pour penser à l’avenir. Quels changements pourraient se produire à l’avenir? C’est essentiel pour les grands projets, mais les frais généraux pour les plus petits. Ne pensez pas à l’avenir! Si un petit site Web d’entreprise effectue des changements fondamentaux, il devra peut-être recommencer à zéro. Ce n’est pas un problème important par rapport au budget global.
Planification d’un projet
Lorsque vous préparez votre liste de tâches pour un projet, tenez compte des réflexions suivantes :
- Réduisez la complexité en réduisant le niveau d’abstraction.
- Séparez les fonctionnalités des fonctionnalités.
- Supposez des exigences non fonctionnelles modérées.
- Identifiez les tâches chronophages et éliminez-les.
Allons un peu dans les détails ! J’ai déjà fourni un exemple pour le premier élément de la liste: n’enveloppez pas un pilote de base de données autour d’une couche d’abstraction de base de données. Méfiez-vous de tout ce qui ajoute de la complexité à votre pile logicielle. Notez que l’abstraction est souvent fournie par des bibliothèques tierces. Par exemple – selon votre langage de programmation -, une couche de persistance, comme Hibernate (Java), Doctrine (PHP) ou Active Record (Ruby) est livrée avec une abstraction de base de données et un mappage objet-relationnel. Chaque bibliothèque ajoute de la complexité. Il doit être maintenu. Des mises à jour, des correctifs et des correctifs de sécurité doivent être appliqués.
Nous implémentons des fonctionnalités tous les jours, car nous anticipons leur utilité. Par conséquent, nous pensons à l’avenir et nous mettons trop en œuvre. Par exemple, de nombreux clients souhaitent avoir un site Web mobile. Mobile est un terme de compréhension large; ce n’est pas une décision de conception. C’est un cas d’utilisation ! Les personnes qui utilisent un site Web mobile sont, eh bien, mobiles. Cela signifie qu’ils peuvent vouloir accéder à d’autres informations ou fonctionnalités qu’un utilisateur qui visite le site décontracté sur son bureau. Pensez à un site de cinéma: Les utilisateurs du bus voudront probablement accéder à l’heure de début des films à venir, pas à la bande-annonce de 50 Mo.
Les mauvais concepts peuvent souvent être identifiés par l’absence d’exigences non fonctionnelles.
Avec un budget approprié, vous effectueriez une analyse dédiée des exigences pour le mobile. Sans cette analyse, vous fournirez simplement les mêmes informations que sur le site de bureau. Ce sera très bien pour de nombreuses circonstances! Parce que les navigateurs mobiles sont très intelligents pour ajuster les sites de bureau à leur affichage, une approche radicale de YAGNI pourrait être de ne pas écrire du tout de site mobile!
Les exigences non fonctionnelles ne décrivent pas le comportement d’un logiciel, elles décrivent des propriétés supplémentaires pouvant être utilisées pour juger de la qualité d’un logiciel. Étant donné que la description de la qualité des logiciels suppose des connaissances sur les logiciels, les mauvais concepts peuvent souvent être identifiés par le manque d’exigences non fonctionnelles. La maintenabilité, le niveau de documentation et la facilité d’intégration sont des exemples d’exigences non fonctionnelles. Les exigences non fonctionnelles doivent être mesurables. Par conséquent, « La page devrait se charger rapidement. »est trop peu concret », la page devrait se charger en deux secondes maximum lors d’un test de performance moyen. » est très concret et mesurable. Si vous souhaitez appliquer le principe de YAGNI, supposez des exigences non fonctionnelles modérées si elles ne sont pas mentionnées dans le concept (ou si elles sont mentionnées, mais non concrètes). Si vous écrivez vous-même les exigences non fonctionnelles, soyez réaliste: une petite entreprise avec 20 à 50 visites de pages par jour ne nécessite pas trois jours de modification des performances – car la page doit se charger assez rapidement car le serveur n’est pas occupé. Si la société peut augmenter le nombre de visites quotidiennes, un meilleur serveur ou un forfait d’hébergement ne devrait pas être trop coûteux.
Dernier point, mais non le moindre, souvenez-vous de la règle empirique du 80:20 !
Dernier point, mais non le moindre, rappelez-vous la règle empirique du 80:20 ! Nous devons identifier les parties qui prennent du temps. Si une pièce est absolument nécessaire, vous devez la mettre en œuvre. La question devrait être: comment allez-vous le mettre en œuvre? Doit-il s’agir du dernier cadre avec une petite communauté? Avez-vous besoin de passer à la version qui vient de sortir d’une bibliothèque si la documentation n’est pas à jour? Devriez-vous utiliser le nouveau CMS, lorsque toutes les extensions ne sont pas disponibles? Combien de recherches seront nécessaires pour le faire? « C’est comme ça que nous l’avons toujours fait. »ce n’est pas une approche passionnante, mais cela permettra de faire le travail sans surprises.
Il est important de comprendre que tout cela ne signifie pas que vous pouvez commencer à écrire du code sale avec des hacks en cours de route! Vous écrivez une application légère, pas une application désordonnée! Cependant, vous n’en aurez pas besoin, c’est une approche pratique. Si cela entraînait de nombreuses lignes de code pour réduire quelques lignes de doublons de code, je pense personnellement que vous pouvez relier les efforts au budget et qu’un certain manque de rigueur est acceptable. C’est une petite application. Par conséquent, la complexité de maintenance supplémentaire est acceptable. Nous sommes dans le monde réel.
Revenons à la pensée initiale: nous aimons construire des choses. Lorsque Beethoven a écrit les Variations Diabelli, c’était un travail contractuel. Je ne pense pas qu’il ait fait des compromis sur le budget. Il a fait un effort supplémentaire, car il ne voulait pas écrire de musique moyenne; il voulait écrire une composition parfaite.
Je ne sous-entends certainement pas que nous sommes tous des génies, et que notre brillance devrait briller à travers chaque ligne de code, mais j’aime penser l’architecture logicielle comme des compositions. Je suis un développeur passionné, car je veux construire des compositions parfaites, et je veux être fier des choses que je construis.
Si vous voulez être un développeur expérimenté et à l’épreuve des affaires, vous devez maîtriser le principe Vous n’en aurez pas besoin. Si vous voulez garder votre passion, vous devez vous battre contre elle de temps en temps.
Résumé
Les principes logiciels sont une façon de voir les logiciels. Pour moi, un bon principe devrait être basé sur un concept simple, mais il devrait évoluer vers une construction complexe d’idées lorsqu’il est confronté à d’autres techniques et philosophies. Quels sont vos principes logiciels préférés ?